- Java Reference Guide
- Overview
- Table of Contents
- J2SE: Standard Java
- Java Windows NT Services
- Advanced J2SE
- J2SE 1.5.0: "Tiger"
- Java SE 6
- Core Computer Science Principles in Java (Data Structures)
- Annotations
- Java Generics
- Java New I/O
- Java Sound
- Java Applets
- JavaFX
- Java SE Threading
- Resource Management Using Semaphores
- Java Atomic Operations
- JavaTemplate Pages
- Executing Templates with the JtpExecutor
- Java Cryptography Extensions (JCE)
- Java Database Connectivity (JDBC) API
- Jakarta Commons - Net Class Library
- Jakarta Commons HttpClient
- Apache POI
- Regular Expressions
- JavaMail
- Cool Tools
- Building an Really Simple Syndication (RSS) Java App
- Logging with Log4J
- Inside Swing
- Swing Components
- SwingX New
- Swing Styled Documents
- Web Rendering in Java Swing Applications
- Java Look-and-Feel Graphics Repository
- Java Media Framework
- Quicktime for Java
- Media in Java Review 2008
- Graphs and Charts
- Holiday Special: Electronic Greeting Card
- Media Framework: Presenter Application
- Standard Widget Toolkit
- JFace
- Java Performance Tuning
- J2EE Performance Tuning
- Caches and Pools
- Java Caching System
- Java Compression and Decompression
- Obfuscating Java Applications
- Continuous Integration
- Load Testing
- Tomcat Clustering
- Enterprise Java Testing
- Automated Unit Testing with JUnit and Ant
- Unit Testing: Tips From The Trenches
- Custom Ant Tasks
- Extensible Markup Language (XML)
- Java Web Technologies
- Web Frameworks
- Struts 2
- Wicket New
- JavaServer Faces
- Distributed Programming / RMI
- Servlet Filters
- Building a Robust Java Server
- J2EE: Enterprise Java
- Spring
- Java Design Patterns
- Gang of Four
- Abstract Factory Pattern
- Template Pattern
- Singleton Pattern
- Builder Pattern
- Prototype Pattern
- Adapter Pattern
- Bridge Pattern
- Observer Pattern
- Command Pattern
- Strategy Pattern
- Transfer Object Pattern
- Proxy Pattern
- Flyweight Pattern
- Decorator Pattern
- Facade Pattern
- A Real World Application
- Session Façade Pattern
- Data Access Object Pattern
- Front Controller Pattern
- Service Locator Pattern
- Books and E-Books
- Online Resources
- Official Documentation
- XDoclet
- Hibernate
- Project Backup
- J2EE Project: Hands-On
- Enterprise Java Beans (EJB) 3.0
- Disaster Recovery
- Java Management Extensions (JMX)
- Service-Oriented Architecture
- Web Services
- Project: Building a Web Photo Gallery
- J2ME: Micro Java
- Specialized J2ME
- Optional Packages
- Other Java Technologies
- Derivatives and Competitors
- Java, Engineered for Integration
- Additional Resources
- The World of Java Tools
- Building Java Applications with Ant
- Managing Java Build Lifecycles with Maven
- Source Control with Subversion
- Inversion of Control and Dependency Injection
- Certification
- Roadmap: Becoming an Enterprise Java Developer
- Roadmap: Becoming an Enterprise Java Developer in 2007
- The Business of Enterprise Software
- JavaOne 2006
- JavaOne 2007
- JavaOne 2008 Wrap-Up
- JavaOne 2009 Wrap-Up
- How to Survive in a Turbulent Job Market
- How to Hire the Best Talent
- Cloud Computing
- Enterprise Java in 2008 and Beyond
- Predictions for 2018
Data Access Object Pattern
Last updated Jan 1, 2004.
The Data Access Object Pattern, also known as the DAO pattern, abstracts the retrieval of data from a data resource such as a database. The concept is to "separate a data resource's client interface from its data access mechanism."
The problem with accessing data directly is that the source of the data can change. Consider, for example, that your application is deployed in an environment that accesses an Oracle database. Then it is subsequently deployed to an environment that uses Microsoft SQL Server. If your application uses stored procedures and database-specific code (such as generating a number sequence), how do you handle that in your application? You have two options:
Rewrite your application to use SQL Server instead of Oracle (or add conditional code to handle the differences), or
Create a layer inbetween your application logic and the data access
The Data Access Object pattern does the latter.
The benefits of the DAO pattern are obvious, but the implementation is a little tricky. To properly implement the DAO pattern you need to generate the following components:
DAO Interface
DAO Factory
DAO Implementation classes
Deployment Descriptor Entry
The DAO pattern, in and of itself, does not necessarily require a factory, but in practice you will see the two patterns coupled. The reason is that some mechanism needs to be created to obtain the appropriate implementation class and using a factory is the cleanest implementation.
DAO Interface
The DAO interface defines all the methods that your data access objects will provide. For a database, these include things like inserting, deleting, updating, and retrieving rows. Because it is an interface, the methods will not be implemented. Listing 1 shows a sample DAO interface.
Listing 1. SampleDAO.java
package com.informit.myejb.dao;
public interface SampleDAO
{
public SampleModel create( long id, String name, String data ) throws
SampleDAOException;
public void delete( long id ) throws SampleDAOException;
public void update( long id, SampleModel model ) throws
SampleDAOException;
public SampleModel[] findByName( String name ) throws
SampleDAOException;
public SampleModel findById( long id ) throws SampleDAOException;
}
The SampleDAO interface presumes a SampleModel object that represents one unit of data. Listing 2 shows the implementation of this hypothetical class.
Listing 2. SampleModel.java
package com.informit.myejb.model;
public class SampleModel
{
private long id;
private String name;
private String data;
public SampleModel( long id, String name, String data ) {
this.id = id;
this.name = name;
this.data = data;
}
public long getId() {
return id;
}
public String getName() {
return name;
}
public String getData() {
return data;
}
public void setName( String name ) {
this.name = name;
}
public void setData( String data ) {
this.data = data;
}
}
The class that eventually uses the implementation of this interface will use it via this interface, and not through the implementation itself.
DAO Implementation
We need a class that performs the actual data access; this will be the function of the DAO implementation class. Its job is to translate the general request for information to a request specific to the data source it represents. For database access, I usually suggest the following:
JDBC Generic implementation: this is an implementation that uses only JDBC and standard SQL
Database vendor specific implementation number one: e.g. Oracle
Database vendor specific implementation number two: e.g. SQL Server
Database vendor specific implementation number ...
Listing 3 shows a sample implementation of the DAO implementation class.
Listing 3. SampleDAOJDBCImpl.java
package com.informit.myejb.model;
import java.sql.*;
public class SampleDAOJDBCImpl implements SampleDAO
{
public SampleModel create( long id, String name, String data ) throws
SampleDAOException {
try {
Connection conn = getConnection();
PreparedStatement ps =
conn.prepareStatement( "INSERT INTO sample VALUES( ?, ?, ? )" );
ps.setLong( 1, id );
ps.setString( 2, name );
ps.setString( 3, data );
ps.executeUpdate();
return new SampleModel( id, name, data );
}
catch( SQLException e ) {
throw new SampleDAOException( e );
}
}
public void delete( long id ) throws SampleDAOException {
// Similar: DELETE FROM sample WHERE id = ?
}
public void update( long id, SampleModel model ) throws
ampleDAOException {
// Similar: UPDATE sample SET name = ?, data = ? WHERE id = ?
}
public SampleModel[] findByName( String name ) throws
SampleDAOException {
// Similar: SELECT FROM sample WHERE name = ?
}
public SampleModel findById( long id ) throws SampleDAOException {
// Similar: SELECT FROM sample WHERE id = ?
}
}
At runtime, this is the class that will perform the data access on our behalf.
DAO Factory
We need a mechanism for determining what class to load at runtime and use in our application. This is the job of the DAO factory class.
The factory class is used in another pattern, the Factory Pattern. The purpose of the factory pattern is to defer the choice of an implementation class until runtime. You ask the factory to create a class that implements a specific interface and (given some piece of additional environmental information), the factory creates the appropriate class.
In the case of an EJB deployment, the additional environmental information is usually specified through the EJB's deployment descriptor. In a stand-alone environment, you can specify it with Java system properties or a configuration file (such as an XML file or properties file).
Listing 4. SampleDAOFactory.java
package com.informit.myejb.dao;
// Import the JNDI classes
import javax.naming.NamingException;
import javax.naming.InitialContext;
public class SampleDAOFactory {
private static SampleDAO dao = null;
public static SampleDAO getDAO() throws SampleDAOException
{
// If we already have loaded the BookDAO, return it
if ( dao != null ) {
return dao;
}
try {
InitialContext ic = new InitialContext();
String className = ( String )ic.lookup( "SAMPLEDAO.Impl" );
dao = ( SampleDAO )Class.forName( className ).newInstance();
}
catch( NamingException ne ) {
throw new SampleDAOException( ne );
}
catch( Exception se ) {
throw new SampleDAOException( se );
}
return dao;
}
}
The SampleDAOFactory class maintains a static reference to the SampleDAO class. The first time the DAO object is requested, the factory looks up the fully qualified class name of the implementation class specified by the deployment descriptor key: "SAMPLEDAO.Impl". It uses the InitialContext class to access the Java Naming and Directory Interface (JNDI) and then calls its lookup() method to find the String value. Finally, it loads the class dynamically by calling Class.forName() and casting it to SampleDAO.
Deployment Descriptor Entry
The final piece of information to get into the system is the association between "SAMPLEDAO.Impl" and the actual class that implements the SampleDAO interface (com.informit.myejb.dao.SampleDAOJDBCImpl). This is accomplished by creating an <env-entry> entry in the ejb-jar.xml file. Listing 5 shows an excerpt from this file.
Listing 5. Excerpt from ejb-jar.xml
<ejb-jar>
<enterprise-beans>
<entity>
<description>Sample Bean</description>
<ejb-name>SampleBean</ejb-name>
<home>com.informit.myejb.ejb.SampleHome</home>
<remote>com.informit.myejb.ejb.Sample</remote>
<ejb-class>com.informit.myejb.ejb.SampleEJB</ejb-class>
<persistence-type>Bean</persistence-type>
<prim-key-class>com.informit.myejb.ejb.SamplePk</prim-key-class>
<reentrant>False</reentrant>
<env-entry>
<env-entry-name>SAMPLEDAO.Impl</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>com.informit.myejb.dao.SampleDAOJDBCImpl</env-
entry-value>
</env-entry>
...
</entry>
...
</enterprise-beans>
<ejb-jar>
In this case, we define a java.lang.String key named "SAMPLEDAO.Impl" to be "com.informit.myejb.dao.SampleDAOJDBCImpl". This will make a JNDI entry into any class owned by the SampleBean class.
Summary
The Data Access Object pattern provides a great mechanism for deferring the implementation of data access to an application's runtime. This way, an application can be written without the knowledge of what database it will be connected to during deployment. Furthermore, it supports expandability, as deployment to a new database only requires a new DAO class and the modification of a deployment descriptor.
The Data Access Object pattern does not need to be used exlusively for databases. Rather, you can use it whenever you need to access data from any resource. One very practical example was in an application that could run both over the Internet or stand-alone; in the stand-alone version, the application retrieved its data from the local file system, while in the Internet-based version it retrieved its data by making requests from the server.




Account Sign In
View your cart