Single DAO & generic CRUD methods (JPA/Hibernate + Spring)

Here is an example interface:

public interface GenericDao<T, PK extends Serializable> {    T create(T t);    T read(PK id);    T update(T t);    void delete(T t);}

And an implementation:

public class GenericDaoJpaImpl<T, PK extends Serializable>     implements GenericDao<T, PK> {    protected Class<T> entityClass;    @PersistenceContext    protected EntityManager entityManager;    public GenericDaoJpaImpl() {        ParameterizedType genericSuperclass = (ParameterizedType) getClass()             .getGenericSuperclass();        this.entityClass = (Class<T>) genericSuperclass             .getActualTypeArguments()[0];    }    @Override    public T create(T t) {        this.entityManager.persist(t);        return t;    }    @Override    public T read(PK id) {        return this.entityManager.find(entityClass, id);    }    @Override    public T update(T t) {        return this.entityManager.merge(t);    }    @Override    public void delete(T t) {        t = this.entityManager.merge(t);        this.entityManager.remove(t);    }}

Based on the article Don't repeat the DAO we used this kind of technique for many years. We always struggled with problems with our patterns after we realized that we made a big mistake.

By using an ORM tool such as Hibernate or JPA you will not have to think DAO and Service layer separately. You can use EntityManager from your service classes as you know the lifecycle of transactions and the logic of your entity classes there.

Do you save any minute if you call myDao.saveEntity instead of simply entityManager.saveEntity? No. You will have an unnecessary dao class that does nothing else but will be a wrapper around EntityManager. Do not afraid to write selects in your service classes with the help of EntityManager (or session in hibernate).

One more note: You should define the borders of your service layer and do not let programmers to return or wait for Entity classes. The UI or WS layer programmers should not know at all about entity classes only about DTO-s. Entity objects have lifecycles that most of the programmers do not know about. You will have really serious issues if you store an entity object in a session data and try to update it back to the database seconds or hours later. Well you may would not do it but a programmer of the UI who knows the parameter types and return types of your service layer only would do to save some lines of code.

I was looking for this same thing. I found what appears to be exactly that- the Spring-Data JPA project provided by SpringSource. This is a code port from Hades and has now (Early 2011) been swallowed by Spring and better integrated.It allows you to use a single dao (SimpleJpaRepository) with a static create, or extend the base JpaRepository class to create any object specific dao with ready made CRUD+ methods. Also allows grails like queries just by using params names as the name of the method- in the interface (no implementation required!) i.e. findByLastname(String lastName);Looks very promising- being part of Spring projects will certainly ensure some future for it too.I have begun implementing this in my upcoming project now.