¿Por qué usar la capa de servicio?

Question

Miré el ejemplo en http://solitarygeek.com/java/developing-a-simple-java-application-with-spring/comment-page-1#comment-1639

Estoy tratando de averiguar por qué la capa de servicio es necesaria en primer lugar en el ejemplo que proporciona. Si lo sacó, a continuación, en su cliente, usted podría hacer:

UserDao userDao = new UserDaoImpl(); 
Iterator users = userDao.getUsers(); 
while (…) { 
… 
} 

Parece que la capa de servicio es simplemente una envoltura alrededor de la DAO. ¿Puede alguien darme un caso en el que las cosas se vuelvan complicadas si se elimina la capa de servicio? Simplemente no veo el sentido de tener la capa de servicio para comenzar.

Answer 1

Tener la capa de servicio alrededor del DAO es un antipatrón común. En el ejemplo que le das ciertamente no es muy útil. El uso de una capa de servicio significa que usted obtiene varios beneficios:

• se llega a hacer una clara distinción entre la actividad de tipo Web hecho mejor en el controlador y la lógica de negocio genérico que no está relacionada con la web. Puede probar la lógica comercial relacionada con el servicio por separado de la lógica del controlador.

• se llega a especificar el comportamiento de la transacción por lo que si tiene llamadas a múltiples objetos de acceso a datos puede especificar que se produzcan dentro de la misma transacción. En su ejemplo, hay una llamada inicial a un dao seguido de un bucle, que presumiblemente podría contener más llamadas dao. Mantener esas llamadas dentro de una sola transacción y la base de datos funciona menos (no tiene que crear una nueva transacción para cada llamada a un Dao) pero lo más importante es que los datos recuperados serán más consistentes.

• puede anidar los servicios de modo que si uno tiene un comportamiento transaccional diferente (requiere su propia transacción) puede aplicar eso.

• puede usar el interceptor postCommit para hacer notificaciones como enviar correos electrónicos, para que no se cague el controlador.

Típicamente I tienen servicios que abarcan casos de uso para un solo tipo de usuario, cada método en el servicio es una sola acción (trabajo a realizar en un solo ciclo de petición-respuesta) que ese usuario estaría realizando y, a diferencia de su ejemplo, normalmente hay más de una simple llamada a un objeto de acceso a datos que está pasando allí.

Answer 2

Tome un vistazo al siguiente artículo:

http://www.martinfowler.com/bliki/AnemicDomainModel.html

Todo depende de dónde se quiere poner su lógica - en sus servicios o sus objetos de dominio.

El enfoque de capa de servicio es apropiado si tiene una arquitectura compleja y requiere interfaces diferentes a sus DAO y datos. También es bueno proporcionar métodos detallados para que los clientes llamen, lo que llama a múltiples DAO para obtener datos.

Sin embargo, en la mayoría de los casos lo que desea es una arquitectura simple, saltee la capa de servicio y mire el enfoque de un modelo de dominio. Dominio de diseño impulsado por Eric Evans y el artículo InfoQ aquí expandirse en esto:

http://www.infoq.com/articles/ddd-in-practice

Answer 3

El uso de la capa de servicio es un patrón de diseño bien aceptado en la comunidad de Java.Sí, podría usar inmediatamente la implementación de dao, pero ¿qué sucede si desea aplicar algunas reglas comerciales?

Supongamos que desea realizar algunas comprobaciones antes de permitir que un usuario inicie sesión en el sistema. ¿Dónde pondrías esas lógicas? Además, la capa de servicio es el lugar para la demarcación de transacciones.

En general, es bueno mantener la capa de Dao limpia y delgada. Le sugiero que lea el artículo “Don’t repeat the DAO”. Si sigues los principios en ese artículo, no escribirás ninguna implementación para tus daos.

Además, tenga en cuenta que el alcance de la publicación de este blog fue ayudar a los principiantes en la primavera. La primavera es tan poderoso, que se puede doblar para que se adapte a sus necesidades con los conceptos de gran alcance como AOP etc.

Saludos, James