¿Realmente necesito una capa de servicio?

Question

Mi aplicación web está escrita usando Spring MVC + Hibernate.

• Mi modelo es "Cliente" entity POJO.
• Tengo un objeto DAO "CustomerDAO", su método "saveCustomer (c)" contiene el código que interactúa con Hibernate;
• Entonces creó una "CustomerService con un '' método que simplemente pasar el objeto de cliente a la DAO para el ahorro;
• Por último, hay 'saveCustomer (c) CustomerController' y customer.jsp, que son responsables de la capa de vista, los campos de formulario jsp están vinculados a un objeto Cliente en el lado del controlador. El controlador llama al servicio.

Vi muchas aplicaciones seguir esta (mejor) práctica, pero me pregunto por qué necesitaría una capa de servicio.

Quizás es útil para desacoplar p propósito: puedo mostrar una fachada universal a los controladores e insertarla en el servicio HibernateDAO, GaeDAO, MyDAO, etc. ... Pero podría hacerlo sin el servicio: usando una interfaz.

También pensé: validación. Haré mi validación del cliente en el servicio pero .... es mucho más conveniente validar en el controlador de Spring.

Ayúdame a entender el concepto :)

Answer 1

Usted no necesita una capa de servicio. Sin embargo, le ayuda a

• Disociar sus componentes
• Puede aplicar reglas de negocio específicas en su capa de servicios que deben ser agnóstico a su repositorio
• Deje una fachada servicio de uno o más repositorios.Consideremos el siguiente ejemplo de

class Service { 
    private DatabaseBarRepo barRepo; 
    private DatabaseFooRepo fooRepo; 

    @Transactional 
    public void serviceRoutine() { 
    barRepo.doStuff(); 
    fooRepo.doStuff(); 
    } 
} 

Aquí nos vamos dos separados repositorios toman 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.

Answer 2

Hay otras cosas que en la capa de servicio. A veces se trata de aplicar reglas comerciales antes de pasar cualquier acción a DAO. A veces, un servicio necesita interactuar con otros servicios, DAO para el requisito de reglas comerciales.

Dinos cómo harás sin la capa de servidor y con una interfaz ... una idea de alto nivel, me ayudará a contarte más.

Answer 3

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. ¿Es eso toda la aplicación? De lo contrario, cuando comiences a construir las partes no triviales, tu capa de servicio se expandirá.

Answer 4

Puede guardar la verbosidad teniendo un BaseService que tiene todas las operaciones CRUD, delegando en una BaseDAO inyectada en él.

Además de CRUD, casi todo lo demás tiene una lógica separada para la lógica comercial y para las operaciones específicas de la base de datos. Y otra cosa - usted puede tener múltiples operaciones de base de un lapso de transacción anotando los métodos de capa de servicios con @Transactional

Answer 5

La clave es el comportamiento transaccional. Si no tiene una capa de servicio, ¿dónde demarcará las transacciones?

• en la capa de presentación: no es ahí donde pertenece demarcación de transacciones, y no sería capaz de utilizar la demarcación de transacciones declarativa
• en la capa DAO: usted no sería capaz de crear un cliente y su contacto (por ejemplo) en una sola transacción, porque sería usar dos DAOs diferentes

por otra parte, usted quiere que su capa de interfaz de usuario tan simple como sea posible, y el código de negocio (que a veces es mucho más complejo que llamar Sinply un DAO método) aislado en componentes específicos. Esto permite

• unidad de prueba de la capa de interfaz de usuario al burlarse de la capa de servicio unidad
• probar la capa de servicio (el código de negocio) al burlarse de la capa DAO