BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Has JPA Killed the DAO?

Has JPA Killed the DAO?

This item in japanese

Bookmarks

Recently there has been some discussion as to whether or not the Java Persistence API (JPA) has killed the Data Access Object (DAO). JPA (Java Persistence API) defines an interface to persist normal Java objects (or POJO's in some peoples terminology) to a datastore. Essentially this provides object-relational mapping similar to Hibernate and others. On the other hand, a DAO can be summed up as,

A Data Access Object (DAO) is a software component that provides a common interface between the application and one or more data storage devices, such as a database or file.

 

As with most discussions of this nature, bloggers from both sides have taken their stance. On one side, which initiated this discussion, Adam Bien states,

...The usage cannot be simpler. The EntityManager will be just injected to the bean-class...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...
Days later, magle argued that the DAO wasn't going anywhere,
there were some statements and blog posts about the end of the DAO pattern in the last weeks, especially in conjunction with the rising of EJB 3 and it's EntityManager. those proposals suggest to use EntityManager directly inside your business oriented services instead of encapsulating data access logic through a DAO. i strongly disagree with this opinion...
Magle goes on to explain himself through the rest of the article by highlighting on various key issues: In a follow up post to JPA/EJB3 Killed the DAO, Adam Bien continues to spell out his reasoning for why the DAO is no longer necessary,
The DAO-Pattern can be considered as a "Data Service Layer", which encapsulates the particular and often proprietary data access realization. The main purpose of such a layer would be to make your independent of the particular database or OR-mapper. But even in the past I never replaced the database or even switched from SQL to LDAP.
There are some cases, like e.g. encapsulation of legacy systems, were layers are mandatory. DAOs in my opinion can be highly optimized in Java EE 5 (until it disappears :-)). The DAO-Interface, implementation and Factory and the actual Session Bean can be collapsed. Of course we could argue, that it isn't very good to be dependent on EJB 3 - but why not? Just because of @Stateless annotation?

 

On each post there are numerous comments which continue the discussion, such as WarpedJavaGuy:

DAO's will not die any time soon. Persistence and data access are not one and the same.
On the other hand, Antonio Goncalves replies:
Java EE has suffered of so much boiler plate code, design patterns that turned into anti-patterns, complexity and so on, that I have no problem in using EntitManager CRUD operations on my EJBs. For simple application, I skip the DAO pattern...

 

All in all the general consensus is that it all depends on the application and requirements. Adam sums it up,

I would say: it depends. It depends how complex your application really is.

Rate this Article

Adoption
Style

BT