Download J2EE[tm] Design Patterns > Data Access Object (DAO)

Executive Walk Through
Data Access Layer
12/13/01
Scot Witt
Executive Walk Through
Data Access Layer
Table of Contents
Scenario
Intent
Solution
Motivation
Patterns Used
Players
Reservations Implementation Class Model
Sequence Diagram
3
3
3
4
5
5
6
6
7
7
8
9
9
Consequences
Implementation Concerns
Let’s Walk through it . . . . .
All data in this implementation is passed via a Pure Data Object
Confidential
©2001, Kemper Insurance Companies
Page 2
Executive Walk Through
Data Access Layer
1 Scenario: Update Reservations and Gateway Databases
1.1.
Intent
Decouple business logic from data access logic and adapt the accessed resource so
the type of resource can be independent and changed easily.
1.2.
Solution
 BusinessObjects access data through a DataAccessObject, which adapts a
Resource and retrieves data from it.

Use the Data Access Layer pattern:
Confidential

Separate business logic from data access logic.

Support selecting the type of data source used at deployment time.

Changing data source type should have no impact on the data access
carried out by business objects and other clients.
©2001, Kemper Insurance Companies
Page 3
Executive Walk Through
Data Access Layer
2 Motivation
Business components relying on the specific features of an underlying data resource
(like a particular vendor database) tie business logic and data access logic. This
leads to two issues:
1. Applications that use these components are difficult to modify when they use
a different type of resource.
2. The components serve a limited purpose since they are locked into a
particular type of resource.
These problems are addressed by removing data access logic from the application
components and abstracting data access functionality in a separate interface.
Enterprise beans carry the business logic in terms of interface operations
implemented by a data access layer appropriate for the resource.
For example, the implementation scenario ReservationsBusinessObject component
accesses a database through its associated ReservationDAO class. This class
knows how to perform load, save, and find operations on order data in the persistent
store. Because the bean delegates persistence-related tasks to the DAO, it can
concentrate on implementing business methods.
When integrated, the application administrator configures ReservationsDAO to
ReservationsDB2 and GatewayDB2 or, Anyotherdatastore. No the choice, the
ReservationsBusinessObject is unaffected, because it is programmed to an
interface, not to an implementation.
Confidential
©2001, Kemper Insurance Companies
Page 4
Executive Walk Through
Data Access Layer
3 Methodology
3.1.
Patterns Used
The structure of the Data Access Layer implementation involves three design
patterns: Bridge , Adapter and Factory.
3.2.
Abstract Class Model
ClientObject
FactoryMethod
accesses
Uses
BusinessObject
DAOFactory
Bridge:Abstraction
Bridge:Implementor
Adapter:Target
DataAccessObject
ImplementationA
adapts
ImplementationB
adapts
DataStoreA
DataStoreB
Adapter:Adaptee
Adapter:Adaptee
Figure 1 Abstract Layer Class Model
Players
BusinessObject (ReservationsBusinessObject)

abstracts business operations.

maintains a reference to a DAOImplemention.

is unaware of the Resource that's being used.
ReservationsDAOFactory (ReservationsDAOFactory)

gives the name of DAO to be called
DataAccessObject (ReservationsDAO)

abstracts operations on a Resource.

provides a well-defined API for accessing and manipulating data.
Confidential
©2001, Kemper Insurance Companies
Page 5
Executive Walk Through
Data Access Layer
DAOImplementations (ReservationsDB2, GatewayDB2)

implements the DataAccessObject interface.

adapts the interface of the underlying Resource to the DataAccessObject
interface.
Resource (DB2)

provides resource data persistence and retrieval by way of an arbitrary API
which needs adapting.
Reservations Implementation Class Model
accesse
Uses
s
ApplicationCo
ReservationsBusinessO
ReservationsDAOFac
de
bject
tory
ReservationsDataAccessO
bject
ReservationsDB2D
AO
GatewayDB2D
AO
ReservationsD
B2
GatewayD
B2
Sequence Diagram
Confidential
©2001, Kemper Insurance Companies
Page 6
Executive Walk Through
ApplicationCod
e : Reservation
Reservations
BusinessObject
Data Access Layer
Reservations
DAOFactory :
Reservations
DAO :
Reservations
DB2DAO
Reservations
DataStore
Gateway
DB2DAO
Gateway
DataStore :
Create
createFactory()
Create
Method 1 adapt
SetData
setData Successful
Method 2 adapt
SetData
setData Successful
Cust Updated
Consequences
The benefits of this implementation are:
Confidential
©2001, Kemper Insurance Companies
Page 7
Executive Walk Through
Data Access Layer

Greater deployment flexibility. Data access objects represent data sources
through an interface. The implementation of that interface can be configured
at deployment time.

Resource vendor independence. Components that use vendor-specific API
to access data resources lock themselves into using that particular vendor.
The DAO pattern isolates vendor-specific code where it can be easily
replaced.

Resource implementation independence. For example, persistent data
store can be implemented by a relational database, an object database, flat
files in a filesystem, etc.. The DAO pattern allows designers to focus on the
behavior of application objects, and deal with data access mechanisms
separately.

Improved extensibility. New resource types are easy to add, requiring only
a new DAO implementation for the resource type, plus integration of that
class into the existing framework.
The liabilities of this implementation are:

New Technology. This implementation introduces a new way of thinking
which needs to be implemented and proved to win and convert folks.
Implementation Concerns

Using only one type of data access object when there is only one type
of resource. If there is only one type of resource, then a DAO superclass (or
superinterface) isn't required. The bridge to the DAO is still useful, because
changes to the type of resource being used won't affect classes that access
the resource using the DAO.

Choosing the right data access object. An abstract factory can use
deployment configuration data to select a data access object at runtime,
automatically configuring the application to use a particular resource type.

Dealing with different transactional behaviors. Different resource
implementations may have very different transactional behaviors. It may be
hard to decide how to distribute the logic for transactional operations.
Addressed by the use of helper class, which encapsulates information, the
DAO needs to perform its transactional functions.

Dealing with higher memory requirements. Use a cache and remove
duplicate data in the objects using DAOs.
Confidential
©2001, Kemper Insurance Companies
Page 8
Executive Walk Through
Data Access Layer

Using non-database storage. Data Access Objects are not limited to
abstracting database access. The DAO pattern can also be used to access
XML data sources.

Using different persistence mechanisms. Re-implementing the DAL to use
a different persistence mechanism wouldn't affect classes that use the
DAO, since the interface is unchanged.

EJB CMP and Data Access Layer. CMP and the DAL are similar, in that
they abstract data access for an application developer. The only tangible
benefit the DAL pattern offers over CMP is simpler deployment and no
dependency on the existence of an application server container.

As EJB. Data access object can be implemented as a lightweight entity
bean, whose local interface abstracts data access functionality.
In the implementation scenario, the data access objects could be replaced
with lightweight beans that use bean-managed persistence. These beans
could also use container-managed persistence. An relational-object mapping
tool could be used to map the SQL tables that are bundled with the
application to the appropriate objects in the CMP data model.
Let’s Walk through it . . . . .
All data in this implementation is passed via a Serialized Pure Data Object
1. An http request from an html Forms invokes a Servlet to update customer
information in Two databases. The Servlet parses for the request data by calling
getRequest.Parameters() method calls. All the Customer update information is
loaded in a DataObject using it’s set method( ) calls. The Data Object is passed
as Input to a method call in the applications specific code. The application
specific objects perform any business rules validation and logic for verification
and integrity. An instance of ReservationsBusinessObject is created which
calls the Factory to get the appropriate Data Access Object.
2. The getDAO() in the ReservationsBusinessObject method invokes its
namesake in ReservationsDAOFactory to get the appropriate DAO:
public static ReservationsDAO getDAO() throws DAOSysException {
// ...
InitialContext ic = new InitialContext();
String className = (String)
ic.lookup(JNDINames.RESERVATIONS_DAO_CLASS);
reservationsDao = (ReservationsDAO)
Class.forName(className).newInstance();
// ...
return reservationsDao;
}
Confidential
©2001, Kemper Insurance Companies
Page 9
Executive Walk Through
Data Access Layer
3. Once the correct DAO is know, an Instance of it is created and from here
onwards the ReservationsBusinessObject defers all JDBC and/or EJB method
calls to the DAO, which in this case happens to be the ReservationsDAO.
public Integer ejbCreate(Collection lineItems, Address
businessAddr, Address HomeAddr, String FirstName,
String
LastName, String MiddleName,String billTo, )
throws Exception e ....
ReservationsDAO dao = getDAO();
int id = dao.create(this.custDetails);
// ...
}
4. The ReservationsBusinessObject then calls the create() method on the
ReservationDAO, which has the logic needed to create a new item in the
database. Parts of this logic is in the method updateCustomer(), whose
implementation varies for each data store called. The DAO also has the logic to
invoke a 2nd method to send the updateCustomer( ) to the GatewayDB2DAO.
Generic Exceptions are introduced to convert data store specific Exceptions into
generic and application level Exceptions. Logic to provide error handling in case
of either updates failing is also in the ReservationsDAO. Object as well as SQL
based data access methods are available. The first implementation of the
updateCustomer( ) method is in SQL to leverage any existing investment in
SQL and make understanding the implementation a little easier.
ReservationsDAODB2.updateCustomer() is used with the Reservations DB2
database:
stmt = createPreparedStatement(dbConnection, queryStr);
int resultCount = stmt.executeUpdate();
if ( resultCount != 1 )
throw new UpdateException(
"ERROR in Customer table update”
........
GatewayDAODB2 could slightly different depending on the underlying
structure of the data store. A successful update in both cases returns a NULL
to the client application.
6. As mentioned earlier all Data is passed via a Serialized data object.
Exceptions are handled at the DAO level. It is responsible for converting all
system Exception into application Exceptions. The whole implementation can
change with out requiring any change to the Reservations business Object.
Confidential
©2001, Kemper Insurance Companies
Page 10