java - mvc - patrones de diseño spring
¿Qué es DAO y la capa de servicio exactamente en Spring framework? (4)
¿Qué es DAO y la capa de servicio exactamente en Spring framework?
Estoy buscando respuesta teórica.
Aunque pasaron muchos años desde que se hizo esta pregunta, todavía hay personas (como yo) que quieren saber la respuesta a esta pregunta. Además de las respuestas anteriores, quiero compartir lo que encontré:
En muchos códigos básicos basados en Spring escritos para los datos de los aprendices de Spring solo se almacenan y se leen solo desde una base de datos. Y los DAO inyectan SessionFactory. Luego tenemos servicios que parecen estar haciendo lo mismo. Y los nuevos alumnos se preguntan por qué tenemos dos interfaces y clases similares: dao''s y service.
Pero en una aplicación del mundo real puede haber otros tipos paralelos de almacenamiento de datos (por ejemplo, los datos de un tipo podrían almacenarse en una base de datos y algún otro tipo de datos almacenados en un archivo u otros tipos de almacenamiento podrían usarse en un momento dado) ).
Y en este tipo de casos, las clases de Controladores tendrían que inyectar muchos tipos de interfaces diferentes (una que trabaja con DB y otra que trabaja con archivos y otras). Y si hay una aplicación móvil que utiliza las mismas fuentes de datos, la aplicación móvil también configuraría todos los diferentes tipos de fuentes de datos.
Entonces, en lugar de hacer esto, cuando se usan los servicios, las clases de controladores, aplicaciones móviles, etc. pueden usar solo un servicio y el servicio funciona con cualquier número de fuentes de persistencia de datos que tengamos.
Más adelante, cuando se produzca un cambio en el número o el tipo de fuentes de persistencia de datos, el cambio también se realizará en los DAO y el Servicio afectados, por lo que los controladores, las aplicaciones móviles, etc., no se verán afectados; seguirán utilizando el mismo servicio.
Todo esto sensiblemente disminuye el volumen de trabajo a realizar.
Hay un patrón de diseño de Fachada que recomienda esta configuración como un mejor diseño.
Puedes ver una gran representación gráfica de esto en este gran artículo:
https://springframework.guru/gang-of-four-design-patterns/facade-pattern/
Entonces, aunque en las aplicaciones básicas basadas en Spring con una fuente de datos utilizada solo por los usuarios de la aplicación web (controladores) en un escenario de la vida real, la distinción entre DAO y Servicio se vuelve obvia.
Espero que esto ayude.
DAO (objeto de acceso a datos) es un patrón de diseño, que consiste en crear una clase para cada tabla en su base de datos, proporciona una técnica para separar la persistencia de objetos y la lógica de acceso a datos
DAO: objeto de acceso a datos, son objetos para manejar la conexión a su almacenamiento de datos (típicamente, base de datos). Usted tiene aquí sus consultas y DAO proporciona datos a sus servicios.
Los servicios deben contener toda su lógica. Si tiene una lógica separada, teóricamente puede cambiar su capa UI o su capa DAO sin que le afecte.
No hay distinción en lo que se refiere a la primavera. Por convención, puede marcar las clases DAO con @Repository y los servicios con @Service . También el primero hace alguna traducción de excepción de la capa de persistencia.
Ya que está preguntando teóricamente: DAO debe realizar operaciones de base de datos sin procesar y traducirlas a algunas construcciones de nivel superior (objetos, colecciones). Los servicios deben llamar a los DAO y realizar operaciones comerciales. Normalmente, la demarcación de transacciones se realiza en la capa de servicio para abarcar varias llamadas DAO.
Finalmente, DAO debe abstraer la lógica de negocios de los detalles de persistencia, idealmente permitiendo cambiar la capa de persistencia sin cambios de lógica de negocios (servicios). Esto casi nunca es posible debido a la pérdida de abstracción de los proveedores de persistencia (por ejemplo, la carga perezosa).