generic java jpa crud dao genericdao

java - generic - Métodos únicos de DAO y genéricos CRUD(JPA/Hibernate+Spring)



generic dao hibernate (5)

Aquí hay una interfaz de ejemplo:

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

Y una implementación:

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

Siguiendo mi pregunta anterior, las capas DAO y Service (JPA / Hibernate + Spring) , decidí usar solo un DAO para mi capa de datos (al menos al principio) en una aplicación que usaba JPA / Hibernate, Spring y Wicket. Se propuso el uso de métodos CRUD genéricos, pero no estoy muy seguro de cómo implementar esto usando JPA. ¿Podría darme un ejemplo o compartir un enlace al respecto?

Basado en el artículo No repetir el DAO utilizamos este tipo de técnica durante muchos años. Siempre hemos tenido problemas con nuestros patrones después de darnos cuenta de que cometimos un gran error.

Al usar una herramienta ORM como Hibernate o JPA, no tendrá que pensar DAO y Service layer por separado. Puede usar EntityManager de sus clases de servicio ya que conoce el ciclo de vida de las transacciones y la lógica de las clases de entidad allí.

¿Ahorras un minuto si llamas myDao.saveEntity lugar de simplemente entityManager.saveEntity ? No. Tendrás una clase de dao innecesaria que no hace nada más que ser una envoltura alrededor de EntityManager. No tenga miedo de escribir selects en sus clases de servicio con la ayuda de EntityManager (o sesión en hibernación).

Una nota más: debe definir los bordes de su capa de servicio y no permitir que los programadores regresen o esperen las clases de Entity. Los programadores de capas UI o WS no deberían saber nada sobre las clases de entidad solo sobre DTO-s. Los objetos de las entidades tienen ciclos de vida que la mayoría de los programadores desconocen. Tendrá problemas realmente graves si almacena un objeto de entidad en una sesión de datos e intenta actualizarlo a la base de datos segundos u horas más tarde. Bueno, puede que no lo haga, pero un programador de la interfaz de usuario que conoce los tipos de parámetros y los tipos de devolución de su capa de servicio solo lo haría para guardar algunas líneas de código.

Estaba buscando lo mismo. Encontré lo que parece ser exactamente eso: el proyecto Spring-Data JPA proporcionado por SpringSource. Este es un puerto de código de Hades y ahora (principios de 2011) se ha tragado y se ha integrado mejor. Le permite usar un solo dao (SimpleJpaRepository) con una creación estática, o extender la clase JpaRepository base para crear cualquier dao específico de un objeto con métodos CRUD + listos. También permite interrogantes tipo grails usando solo nombres de parámetros como el nombre del método: en la interfaz (¡no se requiere implementación!), Es decir, findByLastname(String lastName); Parece muy prometedor: ser parte de los proyectos de Spring ciertamente asegurará algo de futuro también. Empecé a implementar esto en mi próximo proyecto ahora.