java - mvc - Encontré JPA, o similar, no aliento el patrón DAO
mvc java web ejemplo (3)
DAO se utiliza para la perspectiva de diseño, mientras que JPA es un contenedor "oficial" para 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", puede ser ignorado. Muchas cosas se pueden "ignorar" si el proyecto es lo suficientemente "simple".
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 ya no funcionaría, 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 Bean, 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 sobre eso?
Nota: No digo, de ninguna manera, que el patrón DAO esté obsoleto. De hecho, depende del caso.
Para aplicaciones simples, no veo ningún problema en utilizar 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 ...). Entonces tienes razón, depende :)
Encontrarás algún otro punto de vista iluminado en Has JPA Killed the DAO? en InfoQ, pero no se sorprenderá por el contenido y la conclusión que se pueden resumir como: ya no necesita 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 eso
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 múltiples 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 de nuevo la lógica de transacción en su DAO, es decir, dao.beginTransaction() y dao.commitTransaction() y la use en su lugar desde la capa de servicio.
Según tengo entendido, sugieres que usar EntityManager directamente en las clases de servicio es probablemente mejor que tener una clase DAO contenedora. 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 de 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é debería abstraerse 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).
Entonces, en definitiva, para volver a su punto, depende.