Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

JPA and the elimination of the DAO layer

 
Ray Clark
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?

Thanks
 
harshvardhan ojha
Ranch Hand
Posts: 157
1
Android Java MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 100
Eclipse IDE Hibernate Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Rancher
Posts: 2756
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Generally, Named Query annotations are put in the Entities class file
 
Bill Gorder
Bartender
Posts: 1682
7
Android IntelliJ IDE Linux Mac OS X Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:
http://neovibrant.com/2011/11/30/spring-roo-and-active-record/


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.



 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic