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

I'm no expert in this, but I think the layman's explanation I would give to business object is this: business objects hold instance variables and attributes needed for a data access (e.g database) and business logic (for example, a Java class handling real operations) to communicate.

The business object usually does nothing for itself. For example, a phone can be a business object between a person and a news portal, the phone doesn't do anything itself, it just holds the browser and internet configuration settings needed by both parties.

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

Answer 3

In addition -

When you start implementing all your business classes, I am assuming you already have some couple of DAOs in hand.

Let’s take an example, a blogBO requires blogDAO to create or retrieve an existing blog from the database.

However, a blog contains it’s associated collection of comments. blogBO may have function getComments() that looks into the database using commentBO ( that uses commmentDAO) and reads all comments associated to that blog using that DAO. All these activities belong to business that you are adding in blogBO.

All the underlying DAOs should communicate and returns data to the business layer through TO (transfer object or value object.) However, you should already have an associative value object every of your DAO.

Answer 4

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