Encontré JPA, o similar, no aliento el patrón DAO

Question

Encontré JPA, o similar, no aliento el patrón DAO. No sé, pero me siento así, especialmente con los administradores de JTA administrados por el servidor.

Después de un uso práctico adecuado con el patrón DAO, comencé a diseñar aplicaciones basadas en JPA alrededor de ese patrón. Pero no encaja, IMO. Tiendo a perder bastante las características de JPA y todo.

Bueno, supongamos que desencadena una consulta con bloqueo pesimista y devolvió una lista de entidades de un método DAO. Al regresar, la transacción finaliza y el bloqueo se va (un caso con el administrador de JTA administrado por el servidor). Entonces, no tiene sentido, en términos generales. Sin embargo, hay casos válidos.

Otro ejemplo es mucho más trivial. Supongamos que activa una consulta para obtener alguna entidad, que tiene una asociación de carga lenta de uno a muchos con alguna otra entidad. Al devolver el método DAO, la transacción finaliza. La carga lenta no funcionaría más, simplemente obtienes null o algo así. Para hacer frente a eso, lo cargamos ansiosamente de forma manual. hacemos algo como a.getBList().size().

Por lo tanto, IMO es mejor no hacer un DAO exclusivamente, y hacerlo en su negocio de frijol, de esta manera usted podrá aprovechar esas características útiles. O la API de ORM se puede considerar DAO/Data-layer en sí misma, podría decirse. Entonces, no necesitamos hacer otro.

¿Qué piensan ustedes al respecto?

Nota: No digo, de ninguna manera, que el patrón DAO esté obsoleto. De hecho, depende del caso.

Answer 1

Para aplicaciones simples, no veo ningún problema en utilizar el EntityManager directamente desde los EJB y omitir el patrón DAO (estoy cansado de escribir demasiados códigos). Y mi sensación es que esto es lo que fomentan JPA y la API Java EE.Pero aún puede estar justificado para aplicaciones más complejas (para el acceso a datos desde el procedimiento almacenado, archivos planos ...). Así que tienes razón, depende :)

Encontrarás algún otro punto de vista iluminado en Has JPA Killed the DAO? en InfoQ pero no te sorprenderá el contenido y la conclusión que se pueden resumir como: no lo haces Realmente necesito más el patrón DAO para el acceso a datos estándar, sin embargo puede necesitarlo para algunas situaciones más complejas, pero vivimos mejor sin él.

Answer 2

Si no define el DAO mismo como transaccional, no tendrá esos problemas.

Se supone que la capa de servicio es transaccional, porque se supone que una transacción abarca varias operaciones. Poner cada inserción/actualización en una transacción no es el mejor escenario.

Con la primavera logras eso muy fácilmente. Sin él, quizás incluya nuevamente la lógica de transacción en su DAO, es decir, dao.beginTransaction() y dao.commitTransaction(), y en su lugar, utilice la capa de servicio.

Según tengo entendido, sugieres que usar el EntityManager directamente en las clases de servicio es probablemente mejor que tener una clase contenedora DAO. No estoy de acuerdo por una razón. Al trabajar con la clase DAO (interfaz en el mejor de los casos) en sus clases de servicio, no tiene ninguna dependencia de la API JPA. No tiene que construir objetos Query o los "me gusta". Puede que esta no sea una gran ventaja, pero estarás de acuerdo en que es una mejor práctica. Y luego puede cambiar a JDBC simple, texto plano, XML o lo que sea, solo cambiando el DAO.

Esto, aunque se usa ampliamente como un ejemplo de por qué debe abstraer algo en otra capa, a menudo es simplemente un sobrediseño. Pero a veces el hecho de que todas sus operaciones de acceso a la base de datos pasen por un lugar significa que puede agregar registros, verificaciones de acceso, etc. (Sí, a veces el DAO no es una forma particularmente adecuada de hacerlo).

Por lo tanto, para volver a su punto, depende.

Answer 3

DAO se utiliza para la perspectiva de diseño, mientras que JPA es un contenedor "oficial" para las funciones de acceso a datos. No hay forma de que JPA esté intentando matar a DAO: puede hacer que DAO sea más fácil de implementar, tal vez tan fácil que DAO parece tan simple que puede ignorarse. Pero sin la capa DAO, el beneficio de diseño ya no existe.

Por supuesto, para proyectos "simples", se puede ignorar. Muchas cosas se pueden "ignorar" si el proyecto es lo suficientemente "simple".