Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Enterprise Edition >

Write once, persist anywhere

Implement a Data Access Object pattern framework

By James Carman, JavaWorld.com, 03/01/02

  • Print
  • Feedback
.

Page 3 of 5

  1. It should not target any specific data store type. Since this framework is designed to be data store-independent, the language should avoid introducing features existent in one data store type and not in others.
  2. It should be as robust as possible, providing a vast feature set so that business objects don't need to circumvent the framework to retrieve information from the data store.
  3. It should not introduce many novel or unfamiliar concepts, so as to allow business developers to use the query language with little or no assistance.


Given these requirements, the Object query language (OQL) is an ideal candidate from which to model the DAOQL, as the OQL is a comprehensive, object-based query language, already familiar to many business developers.

The DAO provider architecture

The DaoFactory class's plug-and-play nature and the added abstraction layer between the business objects and the data store provide us with a service provider interface, or SPI (to borrow a term from the JNDI provider architecture), for third-party (or in-house) DAO providers to use. The beauty of this new SPI: it matches exactly the API business objects use. A DAO provider must subclass only the DaoFactory class and implement the Dao interface as necessary for its data source type. Thus, a DAO provider must implement only five methods from the Dao interface and one method from the DaoFactory abstract class. This obligates our DAO provider to a whopping six methods! Admittedly, this is easier said than done, but as you will see, implementing your own DAO provider doesn't have to be such a daunting task, provided you use the right tools.

Implement a JDBC DAO provider

In this section, I show how easily you can implement your own JDBC DAO provider, using a few open source utilities. All the classes you use to implement the JDBC DAO provider are contained in the com.carmanconsulting.dao.jdbc package. First, I devise an object-to-relational mapping model for use throughout the framework. Then, I implement one persistence method, delete(). Finally, I construct a portion of the DAOQL query-processing engine. The primary classes for this provider are JdbcDaoFactory and JdbcDao: 

public class JdbcDaoFactory extends DaoFactory
{
     public Dao createDao();
     void setDomainMapFileName( String domainMapFileName );
     void setDebug( int debug );
     void setDataSourceName( String dataSource );
}
class JdbcDao implements Dao
{
     public void create( Object o );
     public Collection retrieve( String queryString );
     public void update( Object o );
     public void delete( Object o );
     public void close();
}


The JdbcDaoFactory class uses a javax.sql.DataSource object to establish connections to the database. The dataSourceName property represents a JNDI name used to look up the javax.sql.DataSource instance within the default JNDI initial context. The domainMapFileName property locates the configuration file for the object-to-relational mapping model.

The object-to-relational mapping model

The object-to-relational mapping model involves only a few classes:

  • Print
  • Feedback

Resources