DAO y Servicio?

Question

Siempre me enfrento a un problema en el que realmente no puedo pensar en un objeto de servicio que encapsule muchos métodos DAO.

Quiero decir que para mi servlet a veces es suficiente usar un único método DAO, por ejemplo addUser (parámetros de usuario).

Qué es mejor: encapsular métodos DAO con objetos de servicio y usar SIEMPRE únicamente objetos de servicio, aunque signifique literalmente un método de servicio único que invoque un método único o mezcle su uso (algunos métodos de objetos de servicio y algunos desde dao en contexto de servlet), lo que significa que he autoencargados DAO y objetos de servicio dentro del controlador.

¿Mezcla la lógica si empiezo a usar DAO y el objeto de servicio en el mismo lugar?

Answer 1

Creo que esto depende de la situación. Si no tener un DAO va a causar la mezcla de su lógica de negocios y su lógica de acceso a los datos, probablemente sea mejor tener clases separadas.

Sin embargo, si su DAO es "ficticio" y simplemente llama a un método EntityManager, probablemente pueda usarlo directamente en sus objetos de servicio. La idea es tener clases que tengan single responsibilities y sean fáciles de extender y probar. No deberías crear capas por el simple hecho de hacerlo.

Probablemente no use DAO directamente de sus controladores si desea mantener una capa de servicio reutilizable. Prefiero usar EntityManager (o cualquier estrategia de persistencia que esté usando) en la capa de servicio si el DAO no tiene sentido.

Answer 2

Personalmente, normalmente encapsulo las llamadas DAO dentro de los servicios.

Esto me permite hacer todos los servicios transaccionales usando AOP/etc. y usar métodos DAO no transaccionales dentro de esos servicios.

Para servicios triviales, esta es una "capa" adicional, pero IMO una que sirve para un propósito (y la generación de código de un tipo u otro puede usarse para generarlo de todos modos). También es raro que tenga solo La funcionalidad DAO está envuelta en un servicio, sin embargo.

Answer 3

Estoy trabajando con un sistema en el que "no se puede hacer que los controladores interactúen con los DAO". la filosofía de diseño se adoptó en un punto y se creó una capa de servicio para cada componente. La mayoría de los servicios son, como usted describe, simplemente delegando a un DAO. Me opongo a esta filosofía por dos razones.

Uno es el bueno viejo "No vas a necesitarlo". No implemente algo hasta que lo necesite. El hecho de que prevea alguna razón para tener una capa adicional de indirección para hacer algo de lógica adicional, no es seguro de que la necesite. Y cuando termines necesitándolo, probablemente descubrirás que tus expectativas realmente no coincidían con lo que creías antes. Y obtienes un costo adicional, porque ahora tienes que probar dos clases en lugar de una, y no es raro que necesites agregar métodos en dos lugares en lugar de uno.

El segundo es, ¿qué diablos es un servicio de todos modos? Cuando modelo mi dominio, trato de pensar en términos orientados a objetos. Hay usuarios, por lo tanto, la clase de usuario tiene sentido. Hay noticias, por lo tanto, la clase NewsItem tiene sentido. Pero ni siquiera sé qué debe hacer un UserService. Contienen "lógica comercial" para los usuarios? No, para eso está la clase de Usuario.

Si necesita mantener una API estricta para el "mundo exterior", entonces puedo ver un caso para tener una capa adicional que permanece sin cambios. Pero en todos los demás casos, no lo va a necesitar.

Answer 4

Depende. Las razones para DAOs separadas y la capa de servicio son a menudo:

• las limitaciones técnicas (ver transacciones AOP en otra respuesta)
• limitaciones arquitectónicas (DTO < => @Entities transformación entre la capa de servicio y DAO)
• histórica (esto es lo que se está haciendo por X años)
• estético (que sólo tienen una capa que se accede desde la capa de vista)

Uso de Java EE 6 (JBoss AS 7), No tengo estas cargas:

• No AOP - @Stateless and @Transactional se ocupa de las transacciones.
• Sin DTOs - Utilizo @Entidades de JPA hasta la capa de vista.
• No importa la historia.
• Y prefiero simplicidad/menos código sobre estética.

Así que tengo la mayoría de los métodos en la capa DAO. Para algunos casos, operaciones más complejas, creo un bean de servicio y quizás use un extended persistence context.

Mi regla de oro, si un método debe entrar en un grano de servicio:

1. Si se utiliza múltiples DAOs (obviamente)
2. Si se lleva a cabo varias gestor de la entidad llama
3. Si la aplicación es es probable que cambie, por ejemplo búsqueda realizada en JPQL vs. Hibernate Search vs. ElasticSearch.