The moose likes Object Relational Mapping and the fly likes JPA and the elimination of the DAO layer Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "JPA and the elimination of the DAO layer" Watch "JPA and the elimination of the DAO layer" New topic

JPA and the elimination of the DAO layer

Ray Clark
Ranch Hand

Joined: Aug 16, 2012
Posts: 55
My Spring book says that with the introduction of JPA and the abstraction that it provides that there is now a discussion going on in the Java community as to whether the DAO layer is still needed or if the JPA code can be moved to the service layer. What do you guys/gals think?

harshvardhan ojha
Ranch Hand

Joined: Jul 26, 2007
Posts: 157

Hi Ray, As per my understanding and experience i feel more comfortable working with DB logic in DAO layer.
And i keep service layer for implementing my business logic on data that has been prepared in DAO layer like keeping all data in cache or validating data.
lokesh sree
Ranch Hand

Joined: Oct 27, 2009
Posts: 100

As per my understanding, the concept of DAO layer actually was conceptualized during, and belongs to, the JDBC times. It served the purpose of holding all the db related code - like finding the db type, initializing connections appropriately, creating the sql specific to db type etc..
But with the introduction of JPA all these activities are irrelevant as JPA is agnostic of db type.. and hence there really is no node for a DAO layer as such and the JPA code can be executed inside the services itself..
However, though not in its true sense,even now DAO layer can be maintained as such a layer has some advantages:
Will serve as a single layer for all your db queries, rather than having JPA code inside services. Any JPA specific things..exceptions, null checks etc. can be handled inside these itself..

Ray Clark
Ranch Hand

Joined: Aug 16, 2012
Posts: 55
I agree with both of you and thank you for your posts.

Even with JPA you have named queries or HQL in the code with calls to the api that will persist data. I prefer to keep those in a DAO layer even though a lot of the old logic (connections and transaction management for instance) has been abstracted into JPA and Hibernate.
Jayesh A Lalwani
Saloon Keeper

Joined: Jan 17, 2008
Posts: 2746

Generally, Named Query annotations are put in the Entities class file
Bill Gorder

Joined: Mar 07, 2010
Posts: 1682

The Named Query on the Entity thing used to drive me nuts. I would have a repository and I would have to go clicking around to the entity to see my query Luckily with Spring data-jpa that is now a thing of the past for me

So I guess I can see the authors point, but I I still like having a separate DAO or repository layer, and I inject my entity managers there. It just makes more sense in my mind for unit testing, and I think part of it might be that I have just become so accustomed to it. The other approach that is starting to get more attention again lately is the Active Record Pattern. This used to be the only option when using Spring Roo (they have since changed that). There are some convincing arguments for that approach as well (even more so if you use a tool like Roo)

There is a little blog on it here:

To sum it up, I prefer to use Spring data-jpa and have a separate layer for DAO. I can see the arguments for the other approaches though and would not be so bold as to call them wrong or bad. If I did switch though, I think it would be to using the Active Record pattern and not to melding the DAO layer into the services.

[How To Ask Questions][Read before you PM me]
I agree. Here's the link:
subject: JPA and the elimination of the DAO layer
It's not a secret anymore!