集成层模式:Data Access Object—数据访问对象模式

Context
Access to data varies depending on the source of the data. Access to persistent storage,
such as to a database, varies greatly depending on the type of storage (relational databases,
object-oriented databases, flat files, and so forth) and the vendor implementation.
Problem
Many real-world Java 2 Platform, Enterprise Edition (J2EE) applications need to use
persistent data at some point. For many applications, persistent storage is implemented with
different mechanisms, and there are marked differences in the APIs used to access these
different persistent storage mechanisms. Other applications may need to access data that
resides on separate systems. For example, the data may reside in mainframe systems,
Lightweight Directory Access Protocol (LDAP) repositories, and so forth. Another example
is where data is provided by services through external systems such as business-to-business
(B2B) integration systems, credit card bureau service, and so forth.
Typically, applications use shared distributed components such as entity beans to
represent persistent data. An application is considered to employ bean-managed persistence
(BMP) for its entity beans when these entity beans explicitly access the persistent
storage-the entity bean includes code to directly access the persistent storage. An
application with simpler requirements may forego using entity beans and instead use
session beans or servlets to directly access the persistent storage to retrieve and modify the
data. Or, the application could use entity beans with container-managed persistence, and
thus let the container handle the transaction and persistent details.
Applications can use the JDBC API to access data residing in a relational database
management system (RDBMS). The JDBC API enables standard access and manipulation
of data in persistent storage, such as a relational database. The JDBC API enables J2EE
applications to use SQL statements, which are the standard means for accessing RDBMS
tables. However, even within an RDBMS environment, the actual syntax and format of the
SQL statements may vary depending on the particular database product.
There is even greater variation with different types of persistent storage. Access
mechanisms, supported APIs, and features vary between different types of persistent stores
such as RDBMS, object-oriented databases, flat files, and so forth. Applications that need to
access data from a legacy or disparate system (such as a mainframe, or B2B service) are
often required to use APIs that may be proprietary. Such disparate data sources offer
challenges to the application and can potentially create a direct dependency between
application code and data access code. When business components-entity beans, session
beans, and even presentation components like servlets and helper objects for JavaServer
Pages (JSP) pages --need to access a data source, they can use the appropriate API to
achieve connectivity and manipulate the data source. But including the connectivity and
data access code within these components introduces a tight coupling between the
components and the data source implementation. Such code dependencies in components
make it difficult and tedious to migrate the application from one type of data source to
another. When the data source changes, the components need to be changed to handle the
new type of data source.
Forces
Components such as bean-managed entity beans, session beans, servlets, and other
objects like helpers for JSP pages need to retrieve and store information from persistent
stores and other data sources like legacy systems, B2B, LDAP, and so forth.
Persistent storage APIs vary depending on the product vendor. Other data sources
may have APIs that are nonstandard and/or proprietary. These APIs and their capabilities
also vary depending on the type of storage-RDBMS, object-oriented database management
system (OODBMS), XML documents, flat files, and so forth. There is a lack of uniform
APIs to address the requirements to access such disparate systems.
Components typically use proprietary APIs to access external and/or legacy systems
to retrieve and store data.
Portability of the components is directly affected when specific access mechanisms
and APIs are included in the components.
Components need to be transparent to the actual persistent store or data source
implementation to provide easy migration to different vendor products, different storage
types, and different data source types.
Solution
Use a Data Access Object (DAO) to abstract and encapsulate all access to the data
source. The DAO manages the connection with the data source to obtain and store data.
The DAO implements the access mechanism required to work with the data source.
The data source could be a persistent store like an RDBMS, an external service like a B2B
exchange, a repository like an LDAP database, or a business service accessed via CORBA
Internet Inter-ORB Protocol (IIOP) or low-level sockets. The business component that relies
on the DAO uses the simpler interface exposed by the DAO for its clients. The DAO
completely hides the data source implementation details from its clients. Because the
interface exposed by the DAO to clients does not change when the underlying data source
implementation changes, this pattern allows the DAO to adapt to different storage schemes
without affecting its clients or business components. Essentially, the DAO acts as an adapter
between the component and the data source.