What is the suitable DAO structure with jpa2 / eclipselink?

Question

I have JPA entities and you need to follow the logic with them. So far, a huge static database class has been doing this job. This is ugly because every open interface method had a private equivalent that EntityManager used to execute transactions. But I could decide that with their static too! However, I wonder if this is appropriate for the design, especially since the class is responsible for many things. Not surprisingly, the code that I found online in real projects was not easy to understand (then I could also fix my code). Is the code easy to understand here , although it may be more general? Anyway, on top of JDBC. However insightful, why use factories and singleton for DAO?

I have at least a singleton instance of em as follows:

private static final Map<String, EntityManager> ems = new HashMap<String, EntityManager>(); private final EntityManager em; private final EntityManagerFactory emf; public void beginTransaction() { em.getTransaction().begin(); } public void commitTransaction() { em.getTransaction().commit(); } public Database(final String persistenceUnitName) { if(ems.containsKey(persistenceUnitName)){ em = ems.get(persistenceUnitName); }else{ ems.put(persistenceUnitName, em = Persistence.createEntityManagerFactory(persistenceUnitName).createEntityManager()); } emf = em.getEntityManagerFactory(); this.persistenceUnitName = persistenceUnitName; } 

Thus, instantiation is standard, still supporting singleton Connection / EntityManager. On the other hand, I wondered if a singleton was needed first. The advantage is that with several ems I run into blocking problems (not using em.lock ()).

Any feedback? Any real or tutorial code demonstrating DAO with JPA2 and eclipselink?

Answer 1

Personally, I do not see the added shielding value of the EntityManager (which is an implementation of the Domain Store template) with the DAO , and I will use it directly from the services, unless the transition from JPA is a likely event. But, quoting an interesting discussion about JPA and DAO :

Adam said that he only met very few cases where a project switched a database provider, and there were no cases where persistence moved to another thing than RDBM. Why should you pay more for what is unlikely to happen? Sometimes, when this happens, a simpler solution might pay for itself, and it might be easier to rewrite the component.

I fully share the above point of view.

In any case, the question that remains open is the EntityManager life cycle, and the answer is highly dependent on the nature of your application (web application, desktop application).

Here are some links that may help you decide what is appropriate in your case:

• Re: JPA DAO in a desktop application
• Using the Java Persistence API in Desktop Applications
• Eclipselink in RCP J2SE Applications
• Application Development Using EclipseLink JPA (ELUG)
• Interesting discussion about JPA and DAO

And if you really want to go the DAO path, you can:

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

Answer 2

You can use Spring 3. Just follow their documentation for clean design.