I Found JPA, or Alike, Don't Encourage Dao Pattern

I found JPA, or alike, don't encourage DAO pattern

For simple applications, I don't see any problem in using the EntityManager directly from EJBs and skipping the DAO pattern (I'm tired of writing too much code). And my feeling is indeed that this is what JPA and the Java EE API encourage. But it may still be justified for more complex applications (for data access from stored procedure, flat files...). So you are right, it depends :)

You'll find some other enlightened point of views in Has JPA Killed the DAO? on InfoQ but you won't be surprised by the content and the conclusion that can be summarized as: you don't really need the DAO pattern anymore for standard data access, you may however need it for some more complex situations, but we live better without it.

Does make sense to use DAO pattern with ORM systems?

Why do you think that not using DAOs is going to alleviate your detached objects scenarios? I don't think it will. If you want to use ORM, you simply need to re-attach objects sometimes.

In the answer to a related question, I argue that you really should use DAOs.

Pros and cons of the use of the DAO pattern

The problems with DAOs that I have seen is that they typically handle full objects all the time. This creates completely unneeded overhead that wouldn't exist with simple queries. For example, if a drop down is to be created off of database reference data, a DAO user may simply say: "Get me the collection of objects for this table where y ordered by z". Then, that data is used in the dropdown, but typically only for a key/value combination, ignoring everything else in the objects (created data, last user who updated it, whether or not it is active, etc) that was retrieved and mapped. Even if this massaging happens near the DAO call and the objects do not get stored as they are retrieved (which is typically not the case, unfortunately, the objects are often wrapped in a c:forEach (JSP) and iterated over to produce a drop down), it still creates unneeded database and network overhead, not to mention the temporary increase in memory to hold these objects.

Now, this is not to say that a DAO can't be designed to retrieve a Map of reference data - it certainly can. But typically they're used for the full object mapping, which is not what is needed all the time. It is a strength when saving, but a weakness, IMO, when retrieving data - sure, you get all of it - but often you don't need all of it, and it just wastes memory, bandwidth and time.

Good usage of managed entities / proxies with ORM

Thanks to @JBNizet i'm seeing some thing more clearly :

• I should use the value returned by merge() method.
• A managed entity is not always a proxy.
• I don't have to abstract the fact that i use managed entities, this will lead to complex and unefficient code
• I choosed JPA i won't switch for it which is true unless rewriting the full model to stand for something based on non relationnal database.

So i'll just change my update method from the original code and i'll keep the rest.

Java EE Architecture - Are DAO's still recommended when using an ORM like JPA 2?

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.

More resources

• JPA/EJB3 killed the DAO
• DAOs Aren't Dead - But They Either Collapsed Or Disappeared
• ...And Finally, You Should Introduce A DAO If:

Should persistence logic be placed in domain model beans or in DAOs only?

Follow the KISS principle. DAOs are great for abstracting the mechanics of persistence away from the domain logic. The domain objects simply carry state from one layer to the other, usually with very little business logic within them. This means that the domain objects (aka DTOs) can have lots of JPA annotations to indicate persistence with some kind of ORM framework, and also JAXB annotations to allow the DTOs to be marshalled easily to XML for transmission by a web service.

My general tendency is to have a single business object dedicated to operate on a single DTO to alter its state in some manner driven by the business rules. A service (which is the JTA transaction boundary) manages a collection of business objects and essentially forms an application transaction. This follows the general OOD principle of lots of fine grained objects with a very clear purpose.

---

Related Topics