Single DAOs and common CRUD methods (JPA / Hibernate + Spring)

Question

Following my previous question, DAO and service levels (JPA / Hibernate + Spring) , I decided to use only one DAO for my data level (at least at the beginning) in the application using JPA / Hibernate, Spring and Wicket. The use of common CRUD methods has been suggested, but I'm not very sure how to implement this using JPA. Could you give me an example or share a link?

Answer 1

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 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); } } 

Answer 2

Based on the article Don't Repeat DAO , we have used this type of technique for many years. We always struggled with problems with our samples after we realized that we had made a big mistake.

With an ORM tool like Hibernate or JPA, you don't have to look at the DAO and the Service layer separately. You can use the EntityManager from your service classes because you know the transaction life cycle and the logic of your object classes.

Do you save any minute if you call myDao.saveEntity instead of just entityManager.saveEntity ? No. You will have an unnecessary dao class that does nothing, but will be a wrapper around the EntityManager. Don't be afraid to write selections in your service classes using the EntityManager (or sleep session).

One more note: you must define the boundaries of your level of service and not allow programmers to return or wait for Entity classes. UI or WS programmers should not even know about entity classes about DTO-s at all. Entity objects have life cycles that most programmers are unaware of. You will have serious problems if you save the entity object in the session data and try updating it to the database in a few seconds or several hours. Well, you may not do this, but a user interface programmer who knows the parameter types and return types of your service level would only do to save some lines of code.

Answer 3

I was looking for the same thing. I found what looks like this is the Spring-Data JPA project provided by SpringSource. This is a port of code from Hades and is now (early 2011) swallowed by Spring and better integrated. It allows you to use one dao (SimpleJpaRepository) with static creation or extend the base JpaRepository class to create any specific dao object with ready-made CRUD + methods. In addition, it allows you to use queries of the grails type, using parameter names as the name of the method - in the interface (implementation is not required!), findByLastname(String lastName); It looks very promising - participating in Spring projects will certainly provide a future. I started to implement this in my upcoming project now.

Answer 4

If you are looking for a third-party implementation, you can check out http://www.altuure.com/projects/yagdao/ . it is a nnotation-based common DAO infrastructure that supports JPA and hibernate

Answer 5

You can also see http://codeblock.engio.net/data-persistence-and-the-dao-pattern/

Related code can be found on github https://github.com/bennidi/daoism

It has integration with Spring and configuration examples for Hibernate and EclipseLink