DAO pattern in java what is a Business Object

Question

Directly from this oracle article about the J2EE DAO Pattern:

Everything is very clear indeed but the Business Object "participant" (as they call it).

Here I quote the bit I would like more insights about (especially would be useful a real life example (an easy one)).

BusinessObject

The BusinessObject represents the data client. It is the object that requires access to the data source to obtain and store data. A BusinessObject may be implemented as a session bean, entity bean, or some other Java object, in addition to a servlet or helper bean that accesses the data source.

I am trying to use this pattern as an exercise (as a student for the exam OCPJP it requires to understand the DAO Pattern). So far I have my DataSource (mysql database), my transfer object (JavaBean called Person) and my DAO object interfacing properly between the database and the JavaBean (Person).

So again What exactly a Business Object is?

Thanks in advance

Answer 1

Business objects are objects that concentrate all the logic of your application. Use Business Objects to separate business data and logic using an object model.

SEE HERE

Answer 2

The DAO is responsible for getting a business object in a storage independent way. For example you can create a DAO for accessing a customer like

public interface CustomerDAO {
    public Customer getCustomerById(Integer id)

}

and then implement a data access in jdbc

public class JdbcCustomerDao {

    public Customer getCustomerById(Integer id){
        DataSource dataSource ...;

         Connection con = dataSource.getConnection(...);
    }
}

or implement an CustomerDao that accesses a web service or whatelse. The advantage of the CustomerDao is that a client (the code that uses the CustomerDao) is independent of the concreate storage technology. That's why you should desing the DAO API without storage dependencies. A good hint is the import statements of the CustomerDAO interface. If the CustomerDAO import statements contain something like:

import javax.sql.***

you should re-think the design of your API. But keep in mind that you can also introduce API dependencies with strings. E.g.

public Customer findCustomer(String sqlWhereClause){
   ...
}

The business object holds the data an it is the place where you should put the domain logic at. If you are using a rich domain model approach.

For details see Concrete examples on why the 'Anemic Domain Model' is considered an anti-pattern