requestmapping - spring mvc ejemplo
¿Por qué usar la capa de servicio? (3)
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é se necesita la capa de servicio en primer lugar en el ejemplo que proporciona. Si lo sacaste, entonces en tu cliente, simplemente podrías hacer:
UserDao userDao = new UserDaoImpl();
Iterator users = userDao.getUsers();
while (…) {
…
}
Parece que la capa de servicio es simplemente una envoltura alrededor de la DAO. ¿Alguien me puede dar un caso en el que las cosas se puedan ensuciar si se elimina la capa de servicio? Simplemente no veo el punto de tener la capa de servicio para empezar.
Echa un vistazo al siguiente artículo:
http://www.martinfowler.com/bliki/AnemicDomainModel.html
Todo depende de dónde quiere colocar su lógica, en sus servicios o en los objetos de su dominio.
El enfoque de la capa de servicio es apropiado si tiene una arquitectura compleja y requiere interfaces diferentes para sus datos y DAO. También es bueno proporcionar métodos de curso para que los clientes llamen, lo que llama a varios DAO para obtener datos.
Sin embargo, en la mayoría de los casos, lo que desea es una arquitectura simple, por lo tanto, omita la capa de servicio y observe el enfoque del modelo de dominio. El diseño impulsado por dominios por Eric Evans y el artículo de InfoQ aquí amplían esto:
Tener la capa de servicio como una envoltura alrededor del DAO es un anti-patrón común. En el ejemplo que le das, ciertamente no es muy útil. Usar una capa de servicio significa que obtienes varios beneficios:
puede hacer una distinción clara entre la actividad de tipo web que se realiza mejor en el controlador y la lógica comercial genérica que no está relacionada con la web. Puede probar la lógica de negocios relacionada con el servicio por separado de la lógica del controlador.
puede especificar el comportamiento de la transacción, de modo 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 seguida de un bucle, que presumiblemente podría contener más llamadas de dao. Mantener esas llamadas dentro de una transacción significa que la base de datos hace menos trabajo (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 servicios, de modo que si uno tiene un comportamiento transaccional diferente (requiere su propia transacción) puede hacerlo cumplir.
puede usar el interceptor postCommit para hacer notificaciones, como enviar correos electrónicos, para que no se descargue el controlador.
Normalmente, tengo servicios que abarcan casos de uso para un solo tipo de usuario, cada método en el servicio es una única acción (trabajo a realizar en un solo ciclo de solicitud-respuesta) que ese usuario estaría realizando y, a diferencia de su ejemplo, hay Por lo general, más de una simple llamada a un objeto de acceso a datos se realiza allí.
Usar la capa de servicio es un patrón de diseño bien aceptado en la comunidad java. Sí, podría utilizar la implementación de dao de inmediato, pero ¿qué sucede si desea aplicar algunas reglas de negocios?
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 dao limpia y magra. Le sugiero que lea el artículo "No repita el DAO" . Si sigues los principios de ese artículo, no estarás escribiendo ninguna implementación para tus daos.
Además, tenga en cuenta que el alcance de esa publicación de blog fue ayudar a los principiantes en Spring. La primavera es tan poderosa, que puede doblarla según sus necesidades con conceptos poderosos como AOP, etc.
Saludos, James