Core J2EE Pattern: Data Access Object

Core J2EE Patterns

Sun Microsystems, the creators of Java, have develop a set of core J2EE patterns that represent the best practices for enterprise Java development. Using the core J2EE patterns makes application development more productive and code easier to understand and maintain.

The best introduction to the general topic of core J2EE patterns is Core J2EE Patterns: Best Practices and Design Strategies by Dan Malks, Deepak Alur, and John Crupi.

Additional useful information on Core J2EE Patterns is available here:

http://java.sun.com/blueprints/corej2eepatterns/index.html

http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html

Data Access Object Core J2EE Pattern

Business applications almost always need access to data from relational or object databases and the Java platform offers many techniques for accessing this data, including a core J2EE pattern in the form of a DAO. The oldest and most mature technique is to use the Java Database Connectivity (JDBC) API, which provides the capability to execute SQL queries against a database and then fetch the results, one column at a time. Although this API provides everything a developer needs to access data and to persist application state, it is a cumbersome API to develop against.

Java 2 Enterprise Edition (J2EE) offers a newer persistence framework in the form of Entity Beans, a subset of the Enterprise JavaBean (EJB) framework. Although there have been many improvements in the more recent EJB 2.0 specification, many developers are now looking to alternative persistence frameworks, such as Java Persistence API (JPA) and Hibernate DAO. Regardless of the tecnology choice, it always makes sense to use the DAO core J2EE pattern.

The Benefits of the DAO Core J2EE Pattern

The Data Access Object (DAO) core J2EE pattern provides a technique for separating object persistence and data access logic from any particular persistence mechanism or API. There are clear benefits to this approach from an architectural perspective. The DAO core J2EE pattern approach provides flexibility to change an application's persistence mechanism over time without the need to re-engineer application logic that interacts with the core J2EE pattern DAO tier. For example, there may be performance benefits in changing an application's performance mechanism from using Entity Beans to using direct JDBC calls from a session bean, or even a move to an alternative persistence framework, such as Spring. Without a core J2EE pattern DAO tier in place, this sort of transition would require extensive re-engineering of existing code.

The DAO core J2EE pattern also provides a simple, consistent API for data access that does not require knowledge of JDBC, EJB, Hibernate DAO, or Spring interfaces. A typical core J2EE pattern DAO interface is shown below.

public interface CustomerDAO
{
public void insert(Customer customer)
   throws CustomerDAOException;

public void update(CustomerPK pk, Customer customer)
   throws CustomerDAOException;

public void delete(CustomerPK pk)
   throws CustomerDAOException;

public Customer[] findAll()
   throws CustomerDAOException;

public Customer findByPrimaryKey(String email)
   throws CustomerDAOException;

public Customer[] findByCompany(int companyId)
   throws CustomerDAOException;
}

It is important to note that core J2EE pettern DAO does not just apply to simple mappings of one object to one relational table, but also allows complex queries to be performed and allows for stored procedures and database views to be mapped into Java data structures.

Minimizing the Impact of Moving to DAO

CodeFutures' objective is to minimize the importance of the main argument against using DAO core J2EE pattern: the fact that it requires a significant amount of repetitive source code to be produced for no immediate advantage over using JDBC, EJB, or Hibernate directly. For many developers, this disadvantage is good enough reason to ignore the long-term benefits of using a framework-neutral API, especially where there are strict project deadlines. Without the code generation advantages of FireStorm/DAO, it is not easy to justify to a project manager or project sponsor the time and cost of manually writing DAO code, regardless of any future benefits they may see.

DAO Core J2EE Pattern Code Generation

CodeFutures' solution to the manual coding problem is to automate the production of a DAO core J2EE pattern tier, as well as automating the actual implementation logic for whichever persistence framework is deemed appropriate for an application. This approach is easy to adopt because almost all databases use a standard language for defining their structure (SQL).