java - ventajas - Capa de servicio y controlador: ¿quién se encarga de qué?
mvc pdf (2)
En general, un servicio de Spring es transaccional. Las cosas entran en un método de servicio particular porque deben agruparse en la misma transacción. Si desea recuperar un objeto de la base de datos, mezclarlo y guardar la nueva versión, la recuperación y el guardado deben estar en el mismo método de servicio. Entonces, sus métodos de servicio se determinan de acuerdo con lo que necesita que la aplicación haga por el usuario.
Intento restringir a los controladores a realizar tareas relacionadas con la validación de los parámetros http, decidir qué método de servicio invocar con qué parámetros, qué poner en la httpsession o solicitud, a qué vista redirigir o reenviar, o cosas similares relacionadas con la web.
En cuanto a la validación: validar los parámetros de entrada en el controlador es una buena cosa para asegurarse de que nadie pueda romper su aplicación con entradas falsas. La validación en el controlador tiende a asegurar que las entradas estén sintácticamente bien (incluida la detección de ataques de inyección), mientras que la validación a nivel de servicio se trata de asegurarse de que el estado de las cosas en la base de datos sea el esperado.
Por lo tanto, los controladores contienen código de infraestructura de infraestructura web, los servicios contienen código de lógica de aplicación.
En la clase, ahora estamos aprendiendo cómo crear una aplicación Spring, aunque la primavera no está directamente involucrada, aprendimos cómo hacer las interfaces para DAO y los objetos de capa de servicio.
Corrígeme si me equivoco: la capa DAO es bastante abstracta: solo contiene las operaciones CRUD y se usa para leer datos (es decir: obtener todos los objetos, obtener objetos específicos, etc.)
Capa de servicio: contiene servicios para crear cosas y eliminar cosas, aquí es donde debería estar la lógica de negocios.
Ahora todo esto tiene sentido en la capa de servicio; excepto objetos de "actualización". ¿Acabas de poner una función de "actualización" que simplemente guarda el objeto en tu base de datos? ¿O es necesario definir la lógica allí también? Aquí es donde está mi confusión, mi comprensión es que los objetos en primavera son solo POJO. Ahora, ¿quién valida los datos?
Digamos que tengo un Object "hijo" que tiene los SurName : Name , SurName , Gender , Photo , Birthdate SurName . ¿Cómo nombraría los servicios? ¿O dejarías que el controlador se encargue de la validación, lo cual no me parece correcto? Por otro lado, no parece correcto delegar cada setter que necesita ser llamado a la capa de servicio.
Entonces, básicamente: ayúdenme a definir cómo guardar sus objetos a través de la capa de servicio.
Si desea que los controladores puedan persistir en los cambios a un objeto Child , tradicionalmente tendría un método en el servicio llamado algo así como ChildService.update(Child newchild) , que manejará llamar a los DAO correctos para que persistan en la nueva versión de este niño.
Los controladores son libres de solicitar el servicio para un niño, cambiar los campos (posiblemente basándose en la información del usuario): un diseño sensato haría que el controlador trabaje con el POJO infantil y luego solicite al Servicio que persista en el cambio. El modelo POJO no debe saber nada acerca de un controlador, servicio o DAO, sino simplemente mantener los datos como usted sugiere; ciertamente, no le conviene que todas las llamadas a setName() o setGender() como resultado automáticamente una actualización de la base de datos.
En su lugar, el controlador y / o servicio debe adquirir un objeto Child , hacer cualquier trabajo que necesite para el objeto en su unidad de trabajo, y luego solicitar un Servicio (y luego el DAO) para persistir en los cambios.
La validación puede tener lugar en varias capas: el controlador puede querer validar cualquier entrada del usuario web, y el servicio puede querer validar que tiene un objeto Child válido antes de que lo persista. Tiene especial sentido tener un cierto nivel de validación en ambas capas en caso de que desee reutilizar este Servicio en otras capacidades, como exponer una interfaz REST, un front-end diferente, etc.