Data transfer object, Business object & Data access object...

Introduction

To simplify data interactions and increase the code understanding the following entities usually are used:

• Value object (VO);
• Business object (BO);
• Persistence object (PO); 
• Data transfer object (DTO or TO) ;
• Data access object (DAO);

So, let's take a look on each of them more closer.

Value object (VO)

These objects should be immutable so that they look more like primitives and can be easily shared among different threads.It makes your code more type safe and expressive. It also tackles "Primitive obsession" anti-pattern. Good example is using class SecurityCode instead of string or Money instead of decimal. Value objects are things like numbers, dates, money, currency, etc.

There are three main criterion of the correct VO:

• should be immutable;
• should be side-effect free (i.e. all non-constructor methods are queries or accessors);
• equality shouldn't be based on its identity (i.e. two value objects are equal when they have the same value, not necessarily being the same object).

Using (© martin fowler)

If you want to change a value object you should replace the object with a new one and not be allowed to update the values of the value object itself - updatable value objects lead to aliasing problems.

@seeAlso http://blog.joda.org/2014/03/valjos-value-java-objects.html 

http://hillside.net/plop/2006/Papers/Library/ValueObject-%20vo5.pdf

Business object (BO)

It is the object that requires access to the data source to obtain and store data. A Business Object 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.

Using (© oracle)

The BusinessObject is responsible for creating the Transfer Object and returning it to the client upon request. The BusinessObject may also receive data from the client in the form of a Transfer Object and use that data to perform an update.

The Business Object also delegates data load and store operations to the Data Access Object.

Data transfer object (DTO or TO)

These objects you can use at the boundaries of the system. DTO its  just as stupid data container which is used to transport data between layers and tiers.  It mainly contains getters & setters & toString method as well. DTOs are anemic in general and do not contain any business logic.

Using (© oracle)

When the client requests the enterprise bean for the business data, the enterprise bean can construct the Transfer Object, populate it with its attribute values, and pass it by value to the client.

Transfer Object creation varies depending on an application's requirements. It means that DTO can be fully immutable or vice versa (members can be defined as public) or consist of immutable and mutable fields at once (in this case its better to use getters/setters but avoid public variables at all).

Persistent object (PO)

A persistent object is an object that has been assigned a storage location in a federated database. 

Java Persistent objects are instances of POJO classes that you create that represent the table in database.

@seeAlso http://wwwasd.web.cern.ch/wwwasd/lhc++/Objectivity/V5.2/Java/guide/jgdPersistence.fm.html#1013873

Data access object (DAO)

In short its way to reduce coupling between Business logic and Persistence logic. DAO allows you to encapsulate code for performing CRUD operation against persistence from rest of application.

Using (© oracle)

Use a Data Access Object (DAO) to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data.

The advantage of the DAO layer is that if you need to change the underlying persistence mechanism you only have to change the DAO layer, and not all the places in the domain logic where the DAO layer is used from.

@seeAlso http://javarevisited.blogspot.com/2013/01/data-access-object-dao-design-pattern-java-tutorial-example.html
DAO Design Problems

Example

import java.util.List;

/**
 * An interface to access the user settings.
 */
public interface CustomerDAO 
{
    // Note: it can manipulate some TO objects instead, depends of requirements.
    List<СustomerVO> findAll();    
    
    List<СustomerVO> find(Long customerID);

    void save(List<СustomerVO> customerList);

    void clear(Long customerID);
}

...