|
|
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
The Data Access Object (DAO) pattern provides an abstraction layer between the business logic tier (business object) and the persistent storage tier (data source). Business objects access data sources via data access objects. This abstraction layer encapsulates the persistent storage type/vendor implementation. Ideally, changes made to the data source, such as switching database vendors or type, should not modify the business objects; only the data access objects themselves would need to change.
In this article, I explore a simple yet powerful framework for implementing the DAO design pattern. First, I describe a typical DAO pattern implementation strategy, noting its shortcomings. Then, I move on to the new implementation, explaining its classes. I also explore an example implementation using the JDBC (Java Database Connectivity) API as the storage mechanism. Finally, I present a wish list for future enhancements.
Sun Microsystems suggests a DAO pattern implementation in the J2EE Pattern Catalog that uses the Abstract Factory and Factory Method design patterns (see Design Patterns) and usually involves an interface similar to:
public interface DaoFactory
{
public CustomerDao createCustomerDao();
public AccountDao createAccountDao();
}
Here, the DaoFactory interface acts as the abstract factory, and the createCustomerDao() method acts as the factory method. In this example, data source-specific classes implement CustomerDao and AccountDao interfaces (or abstract classes); those interfaces typically resemble the following:
public interface CustomerDao
{
public List getCustomersByLastName( String lastName );
public Customer getCustomerBySSN( String ssn );
}
Although this implementation provides adequate data source-type independence, it introduces object type dependence. For example,
adding another object type, say Vendor, to the business domain involves introducing a new VendorDao interface and adding a new getVendorDao() method to the DaoFactory interface.
To provide object type independence, you must simplify the DaoFactory class and add another layer to the DAO implementation hierarchy (the Dao interface) as follows:
public abstract class DaoFactory
{
public final DaoFactory getInstance() throws DaoException;
public abstract Dao createDao() throws DaoException;
}
public interface Dao
{
public void create( final Object object ) throws DaoException;
public Collection retrieve( final String queryString) throws
DaoException;
public void update( final Object object ) throws DaoException;
public void delete( final Object object ) throws DaoException;
public void close() throws DaoException;
}
The new, simplified DaoFactory class (now implemented as an abstract class instead of an interface) can remain unchanged as you add new object types to
the business domain, as the class merely references the generic Dao interface, not object type-specific DAO interfaces. The DaoFactory class still implements the Abstract Factory and Factory Method design patterns; however, it now also implements the Singleton
design pattern, via the static getInstance() method. The getInstance() method returns a DaoFactory type specified at runtime by an XML configuration file with the following format: