negocio - capas de la arquitectura de java
¿Realmente necesito una capa de servicio? (5)
Mi aplicación web está escrita usando Spring MVC + Hibernate.
- Mi modelo es la entidad "cliente" POJO.
- Tengo un objeto DAO "CustomerDAO", su método "saveCustomer (c)" contiene el código que interactúa con Hibernate;
- Luego creé un método " CustomerService with a" saveCustomer (c) "que simplemente pasa el objeto del cliente al dao para guardarlo;
- Finalmente, hay "CustomerController" y customer.jsp, que son responsables de la capa de vista, los campos de formulario de jsp están vinculados a un objeto de Cliente en el lado del controlador. El controlador llama al servicio.
Vi muchas aplicaciones siguiendo esta (mejor) práctica, pero me pregunto por qué necesitaría una capa de servicio.
Tal vez sea útil para el propósito de desacoplamiento: puedo mostrar una fachada universal a los controladores e inyectar en el servicio HibernateDAO, GaeDAO, MyDAO, etc. ... Pero también podría hacerlo sin el servicio: utilizando una interfaz.
También he pensado: validación. Haré la validación de mi Cliente en el servicio pero ... es mucho más conveniente validar en el controlador Spring.
Ayúdame a entender el concepto por favor :)
En este momento, su capa de servicio es trivial porque su servicio es un ajuste trivial alrededor de los accesos a la base de datos. ¿Eso es todo lo que la aplicación es? De lo contrario, cuando comience a construir las partes no triviales, la capa de servicio se expandirá.
Hay otras cosas que están en la capa de servicio. En algún momento se trata de aplicar reglas de negocios antes de pasar cualquier acción a DAO. A veces, un servicio necesita interactuar con otros servicios, DAO para el requisito de reglas comerciales.
Díganos cómo le irá sin la capa de servidor y con una interfaz ... una idea de alto nivel, me ayudará a contarle más.
La clave es el comportamiento transaccional. Si no tiene una capa de servicio, ¿dónde demarcará las transacciones?
- en la capa de presentación: ahí no es donde pertenece la demarcación de la transacción, y usted no podría usar la demarcación declarativa de la transacción
- en la capa DAO: no podría crear un cliente y su contacto (por ejemplo) en una sola transacción, porque usaría dos DAO diferentes
Además, desea que su capa de UI sea lo más simple posible, y el código de negocio (que a veces es mucho más complejo que simplemente llamar un método DAO) aislado en componentes específicos. Esto permite
- Unidad de prueba de la capa UI burlándose de la capa de servicio
- Unidad de prueba de la capa de servicio (el código de negocio) burlándose de la capa DAO
No necesitas una capa de servicio. Sin embargo te ayuda a
- Desacoplar sus componentes
- Puede imponer reglas comerciales específicas en su capa de servicio que deberían ser ajenas a su repositorio
- Deje una fachada de servicio a uno o más repositorios. Consideremos la siguiente muestra.
class Service {
private DatabaseBarRepo barRepo;
private DatabaseFooRepo fooRepo;
@Transactional
public void serviceRoutine() {
barRepo.doStuff();
fooRepo.doStuff();
}
}
Aquí dejamos que dos repositorios separados tomen parte en la misma transacción. Esto es específico para las bases de datos, aunque los principios también son válidos para otros sistemas.
Puede guardar la verbosidad teniendo un Servicio BaseService que tenga todas las operaciones de CRUD, delegando en un BaseDAO inyectado en él.
Además de CRUD, casi todo lo demás tiene una lógica separada para la lógica empresarial y para las operaciones específicas de la base de datos. Y otra cosa: puede hacer que una transacción abarque varias operaciones de base de datos al anotar los métodos de la capa de servicio con @Transactional