If I’m using an ORM like JPA2 – where I have my entities that are mapped to my database, should I still be using a DAO? It seems like a lot more overhead.
It is. And clearly, Java EE doesn’t encourage using the DAO pattern when using JPA (JPA already provides a standardized implementation of the Domain Store pattern and there isn’t much value at shielding it behind a DAO). I find the DAO to be anti-DRY in such situation.
So for simple cases (actually, most cases), I happily skip the DAO and I have no problem with that. For more complex cases (for example when using stored procedures, flat files), I’d use it. In other words, it depends, as summarized in Has JPA Killed the DAO?. See also the related questions below:
Related questions
- I found JPA, or alike, don’t encourage DAO pattern
- Simple but good pattern for EJB
- What is a good strategy for seprating layers for an appication that can be used online and offline?
- Using JSF, JPA and DAO. Without Spring?
- What’s an appropriate DAO structure with jpa2/eclipselink?
(…) One that contains session beans that implement my DAO’s
Noooo, you certainly don’t want to implement a DAO as a Session Bean:
- You don’t want to create as much (pooled) Session Bean as tables (big waste of resources)
- You don’t want to chain Session Beans everywhere, don’t reproduce errors from the past, this is a known bad practice that doesn’t scale well.
So if you really want to go the DAO way and want the EM to be injected, either implement your DAOs as Spring beans (in Java EE 5) or CDI managed bean (in Java EE 6).
You can have an in memory implementation of the DAO for unit testing your service layer.
If you really want to do unit testing, mock the DAO/EntityManager, there is no difference. And if you want to do integration testing, you can configure JPA to use an in memory database. So at the end, I just don’t buy this argument.
It separates business logic from database access logic
Honestly, I don’t see a big difference between relying on a DAO vs an entity manager, I don’t see how a DAO separate things “better”. Again, I don’t buy this argument.
And to my experience, changing the underlying persistence solution is a very exceptional event and I’m not going to introduce DAOs for something that is very likely not going to happen (YAGNI, KISS).
Is there no middle ground here? Has anyone come across an architecture or implemented an architecture that meets some of the benefits of a DAO layer (most importantly the unit testability of business logic) that I mentioned above, but doesn’t involve all the overhead involved to implement a DAO layer?
I don’t see much middle ground and, as strongly hinted, I don’t use DAOs if I don’t feel the need. And as I said, mock the EntityManager if you want to truly unit test the business logic. It works for me and I’m happy to write less code.