JPA in combination with EJB3 is declining the DAO popularity:
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.


more news...