|
DAO Design Pattern
The Data Access Object design pattern separates the
data access logic from any particular persistence mechanism or API. It provides
flexibility to change an application's persistence mechanism over time without
the need to re-engineer the application logic that interacts with the Data
Access Object tier. The Data Access Object design pattern provides a simple,
consistent API for data access that does not require knowledge of JDBC, EJB,
Hibernate, or JDO interfaces. Data Access Object does not just apply to
simple mappings of one object to one relational table, but also allows complex
queries to be performed and allows for stored procedures and database views to
be mapped into Java data structures.
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. DAO tries to decouple the
business logic from the proprietary resource. It abstracts the underlying data
access implementation for the Business Object. Hence enables a transparent
access to a data source. The Business Object also delegates data load and store
operations to the Data Access Object
Practically the DAO-Pattern is achieved as:
- DAO-Interface (provides a data source-neutral
interface)
- DAO-Implementation (help to access the data source
implementation)
- DAO-Factory (creates the implementation)
- Optional: Service Locator (locates the resources in
JNDI)
It was a very good idea to encapsulate the database access
behind a replaceable and mockable implementation. But it was not the proper
solution. Which lead many developers to look for alternative persistence
frameworks for their Data Access Objects, such as Java Persistence API (JPA) and
Hibernate. The DAO pattern is actually no more interesting for general
data access, but is still needed to access data from stored procedures, flat
files etc.
Now the Java Enterprise Edition (JEE) offers a newer persistence framework in
the form of Entity Beans, a subset of the Enterprise JavaBean (EJB) framework.
Introduction of the Java Persistence API to the Java platform solves two
purposes:
1. JPA simplifies the development of Java EE and Java SE applications using data
persistence.
2. It takes the entire Java community behind a single, standard persistence API.
The Java Persistence API draws upon the best ideas from
persistence technologies such as Hibernate, TopLink, and JDO. Users no
longer face the choice between incompatible non-standard persistence models for
object/relational mapping. Additionally JPA is usable both within Java SE
environments as well as within Java EE, allowing many more developers to take
advantage of a standard persistence API.
The Java Persistence API is a POJO persistence API for
object/relational mapping. It contains a full object/relational mapping
specification supporting the use of Java language metadata annotations and/or
XML descriptors to define the mapping between Java objects and a relational
database. It supports a rich, SQL-like query language (which is a significant
extension upon EJB QL) for both static and dynamic queries. It also supports the
use of pluggable persistence providers.
The main problem in JEE that forced the developers to
access the database using the plain-JDBC like limited query capabilities, no
access to native SQL and lack of dynamic queries. But in EJB 3 (part of Java EE
5 environment) there is no need to use the low level JDBC to access the database
any more.
With EJB3 user can use generic, but powerful Query Language,
as well as Native SQL to fetch not only the persistent objects, but also data
transfer objects and even primitive data types as well. It is even possible to
execute update and delete statements. The JPA already comes with an
EntityManager which provides generic data access functionality. The usage cannot
be simpler. The EntityManager can be easily injected to a bean-class.
|
