DAO with JPA (and service layer/EJB3-Session Beans) or not
June 30th, 2010 § 7 Comments
There is a lot of discussion on internet about whether to have DAOs or not with JPA and service layer or with session beans (which is the service layer).
My personal opinion is more favored towards DAO layer and some reasons for this are following:
1. In most of the database driven projects (except the simple ones), programmers will need to do more than direct fetch/store db calls. Even if Entity relationships are well defined what about reporting data and conditional data you will have to fetch (like fetch all users having bought products above price tag $300 in last 6 weeks). Pretty soon programmers may be writing native queries (sometimes for performance reason, which is valid). If there’s no DAO layer, session beans may get heavily loaded with sql code rather than java code. If we push the sql code down to DAO layer, session beans will be much more focused on processing logic, easier to read and clean.
2. Several “db methods” may have to be reused in different parts of code. For e.g. “Netbanking payments in last 6 weeks” might be required on User History and Payment Reports both. If retrieval of this information is within a session bean method, it will not be easier to re-use this for other session beans. That method will have to be exposed as public method by session bean, which will look odd because that was not what session bean’s contract or purpose was. In stead if there’s a dedicated DAO for Transactions, any session bean can use that. In future if a new functionality also needs to access Transactions information, programmers will know they need to look at DAO layer, they do not need to search which session bean might have this method already in-built.
3. Creating an independent database access layer gives us much more flexibility to re-use that layer in other applications. We just need to build a jar of domain objects and DAO layer classes and add to classpath. And in case required, even a desktop application can call those methods without requiring a web/app server environment. On the other hand if session beans contain db calls, it will be more difficult to achieve.
There are few more reasons like testing database access code independent of app server environment, testing session beans with mock database objects etc.
In summary, there are some very good reasons to keep using DAOs.
In my experience I’ve been using DAO layer always for common operations, save, update, delete and find. I can’t think on any scenario whithout a DAO layer. I’m always doing the same as you, packaging domain and DAO code in the same jar, as I can use on any project.
That’s great!! Of course it makes the whole layer easily reusable.
in addition to all these notes, DAO’s are also essential for managing code duplicates and code reduce.
If you are looking for light weight generic DAO library you can check http://www.altuure.com/projects/yagdao/
Generic DAO framework for JPA and hibernate with (optional ) spring support
I’d especially argue two things:
1. Testability of your service code – a plain EntityManager is not hard to mock but as the client has to invoke quite a few operations on it (create a Query object and the like) writing the mock setup becomes quite tedious. This especially makes testing the service code more complex as you tangle your business code with very low level persistence code. So there’s room for an abstraction in between I’d argue, which nicely segues into…
2. Explicit dependency – an EntityManager is an abstraction aver a data store, a repository (or DAO if you like) is much more than that as it’s dedicated to a particular entity and thus provides query methods tightly related and tailored for that entity. Having a UserRepository as dependency in a service constructor makes the dependency explicit. Just using an entity manager with User.class hides it in the implementation.
For the Spring world there’s a library called Hades (soon to be released as Spring Data JPA) that boils repositories down to defining an interface and various algorithms to derive the query to be executed from the declared query methods. For a short introduction read thisarticle on Infoq.
Cheers,
Ollie
- Hades / Spring Data JPA project lead
Thanks for your comments Oliver.
On #1 – Yes I agree. If service code has to interact with complex em calls, mocking becomes equally complex. Hence DAO/Repository solves that problem.
#2 – I am sure we can inject DAO implementation into session bean instead of explicit dependency (and there’s always a DAO interface like generic DAO at the top).
[...] The busiest day of the year was December 22nd with 524 views. The most popular post that day was DAO with JPA (and service layer/EJB3-Session Beans) or not. [...]
Why can’t JPA be used in DAO objects.
In Each DAO method we can use JPA calls.