I decided to go for a “EntityManagerFinder”, which can be configured to bind either way. And because I do not use @PersistenceContext there is no need for me to have DAO instances where this annotation can be set. The method DAO can become statics and then you can get rid of the DAO interface as well. And since they’re now just static methods, it’s much more convenient to move them into the entity class.

Order.findById(…)
Order.findAll()
etc

If we look at Chris Richardson’s (pre-JPA) book POJOs In Action he too wants to have an abstraction for grouping queries or optional eager loads. He calls them “Repositories”. He actually has sample code which demonstrates swapping between JDO and Hibernate implementations. Clearly with JPA we don’t really need the swap out capabilities. The book explains who the iBatis framework can be used with an alternative set of true DAO/DTO patters to do some high performance search screens without having to pollute your use of ORM by forcing it to “play DTO mapper”.

Where the difference really stands out between what is an old school DAO and how we might want to do things with JPA is the following: with the Chris Richardson approach he names the Repository classes to be part of his domain model that you expose to the client / façades. That is certainly not what you do with an old school DAO from the EJB2 world which was usually deemed to be strictly in the data layer and never to be touched except via a service (as @Carlos says). JPA however makes it respectable to get closer to your persistence store than it was to get close to JDBC, Oracle jPub (shudder), or some-home-brew-dto-mapper. That is one of the point that @Aurelio makes.

Saying that the Repository (aka your JPA DOA) is part of the Domain Model makes sense when we consider that the abstraction is mainly there to encapsulate how findByThisAndThat(…) methods actually set the named parameters of a named query. Any façade which wants to intact with record data structure exposed entities would want to call such finders to obtain things which it would then work with (via services) then perhaps call further loadThat/findOther methods on the Repository (aka your DOA) required to update the presentation view.

I wrote a demo app (for an AJAX framework) and copied the GenericJpaDao that I found on the Loom project. They kindly pointed out that they had upgraded their framework to use an ExtendedEntityManager:

http://loom.svn.sourceforge.net/viewvc/loom/loom/trunk/src/java/org/loom/persistence/ExtendedEntityManagerOperations.java?revision=1682&view=markup

Although I have not tried that I think that looks like it is in alignment with what the Chris Richardson book was documenting pre-JPA in terms of being the respectable “Domain Store” which @Aurelio makes reference to which can be exposed to your façades as part of your Domain Model. Of course it is just a re-labelling of the generic DAO but as the Clean Code book says labels are important (thanks for your post about that book I bought it based on your mention of it).

public class monDaoImpl implements monDao {
    …
    public monEntity save(monEntity e) {
        if (e.getId() == null) {
            entityManager.persist(e);
        }
        else {
            e = entityManager.merge(e);
        }
    }
    return e ;
}

For more details on this please read the blog on saving (detached) entities.

Thanks for your articles.

I have one question, during my project we have realize DAOs like this :

public class myDaoImpl implements myDao {
    …
    public void save(Entity e) {
        if (e.getId() == null) {
            entityManager.persist(e);
        }
        else {
            entityManager.merge(e);
        }
    }
    …
}

But after several mistakes on lazy loading we transform on (we add return e):

public class monDaoImpl implements monDao {
    …
    public monEntity save(monEntity e) {
        if (e.getId() == null) {
            entityManager.persist(e);
        }
        else {
            entityManager.merge(e);
        }
    }
    return e ;
}

We add “return e”, because it seems that Hibernate changes the reference of entity, even if the JPA method signature is “void persist(Object o)” but the other sign “Object merge(Object o)”. After call of persist Hibernate changes the reference of entity to a proxy to manage entity that is monitored by Hibernate”. So, outside the method “save” we lost reference of Hibernate proxy on entity, and we must to reattach then entity to Hibernate session.

you confirm it? Is it a specificity of Hibernate and not JPA?

Nicolas Le Coz (Xebia FR)