What's an appropriate DAO structure with jpa2/eclipselink?

Question

I\'ve JPA entities and need to perform logic with them. Until now a huge static database class did the job. It\'s ugly because every public interface method had an private e

Answer 1

Personally, I don't see the added value of shielding the EntityManager (which is an implementation of the Domain Store pattern) with a DAO and I would use it directly from the services, unless switching from JPA is a likely event. But, quoting An interesting debate about JPA and the DAO:

Adam said that he met only very few cases in which a project switched the database vendor, and no cases in which the persistence moved to a different thing than a RDBMs. Why should you pay more for a thing that it's unlikely to happen? Sometimes, when it happens, a simpler solution might have paid for itself and it might turn out to be simpler to rewrite a component.

I totally share the above point of view.

Anyway, the question that remains open is the lifecycle of the EntityManager and the answer highly depends on the nature of your application (a web application, a desktop application).

Here are some links that might help to decide what would be appropriate in your case:

• Re: JPA DAO in Desktop Application
• Using the Java Persistence API in Desktop Applications
• Eclipselink in J2SE RCP Applications
• Developing Applications Using EclipseLink JPA (ELUG)
• An interesting debate about JPA and the DAO

And if you really want to go the DAO way, you could:

• use Spring JPA support,
• use some generic DAO library like generic-dao, krank, DAO Fusion,
• roll your own generic DAO.

Answer 2

You could consider using Spring 3. Just follow their documentation for a clean design.