The Data Access Object Pattern

The Data Access Object (DAO) pattern is a well-established J2EE pattern discussed in many J2EE books including Core J2EE Patterns, by Deepak Alur, John Crupi, and Dan Malks (http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html).

The primary purpose of the DAO pattern is to separate persistence-related issues from general business rules and workflows. We don't want the business or workflow logic to depend on or have any knowledge of what data access technology is actually used.

The DAO pattern introduces an interface for defining the persistence operations that the business layer can access, hiding the actual implementation. (This approach represents the Strategy Design Pattern.) The implementation for this interface will vary depending on the persistence technology being used, but the DAO interface can largely remain the same. Chapter 10 in Expert One-on-One J2EE Development without EJB, by Rod Johnson and Juergen Hoeller (Wiley, 2004), contains some more in-depth discussion on the DAO pattern itself and why it is not always possible or even desirable to try to define a DAO interface that would remain static regardless of persistence technology used. There are many subtle issues, such as managing access over object lifecycles and explicit save operations.

Important 

We recommend using the DAO pattern to separate business logic from the persistence code. The exception to this rule is when the application's business logic consists of data access operations and not much else. In this case it makes sense to include the data access code in the business operations themselves.

Let's see what this looks like in practice, before digging deeper into API and other details.

Spring provides abstract DAO base classes that provide easy access to common database resources. There are implementations available for each data access technology supported by Spring.

For JDBC there is JdbcDaoSupport and it provides methods to access the DataSource and a pre- configured JdbcTemplate. You simply extend the JdbcDaoSupport class and provide a reference to the actual DataSource in your application context configuration. Here is a brief example:

 public class TestJdbcDao extends JdbcDaoSupport {   private final static String TEST_SQL = "select count(*) from dual";       public int getTestCount() {     return getJdbcTemplate().queryForInt(TEST_SQL);   } }

And here is the corresponding entry in dataAccessContext.xml:

<bean  >   <property name="dataSource">     <ref local="dataSource" />    </property> </bean> 

Spring also provides an abstract DAO support class for each O/R mapping technology it supports. For example, Hibernate has HibernateDaoSupport, iBATIS SQL Maps has SqlMapClientDaoSupport, JDO has JdoDaoSupport, and OJB has PersistenceBrokerDaoSupport. We will look at the configuration for a Hibernate DAO that is part of the sample application:

 public class HibernateBoxOfficeDao extends HibernateDaoSupport                                  implements BoxOfficeDao { ...       public Show getShow(long id) {     Show s = (Show) getHibernateTemplate().get(Show.class, new Long(id));     return s;   }       ...     }

And here is the bean configuration from dataAccessContext.xml:

<!-- The Hibernate DAO class --> <bean    >   <property name="sessionFactory">     <ref local="sessionFactory"/>   </property>  </bean>

The configuration for the other data access technologies is similar; simply replace the sessionFactory property with a reference to the corresponding factory type.