This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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?
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.
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..
( SCBCD 5, CCENT, SCJP 5 )
Joined: Aug 16, 2012
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.
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)
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.