Mejores prácticas de DAO (objetos de acceso a datos): ejemplos que veo utilizan un DAO y un objeto de servicios, ¿cuál es la mejor práctica aquí?

Question

Estoy creando un objeto de acceso a datos para recuperar información de Google App Engine para una aplicación web basada en el marco Spring (la primera vez para todos).

Veo una serie de ejemplos que usan un controlador/aplicación web -> Servicio -> DAO -> JDO/Google-App-Engine.

En este patrón, la capa DAO es la única que conoce acerca de JDO, por lo que esta capa es la única que necesita reemplazo si el almacén de datos cambió. La capa Servicios llama a la capa DAO y formatea/manipula los datos necesarios.

Mi pregunta es ¿por qué la capa de servicio adicional? Al menos inicialmente, no parece que la capa de Servicio esté agregando mucho a la ecuación. Naturalmente, pienso simplemente escribir una capa DAO para encapsular las solicitudes JDO y manipular y devolver los datos.

¿Alguien me puede mostrar lo racional de una capa de servicios por separado, será obvio ya que el proyecto se vuelve más grande y complejo?

Answer 1

Normalmente coloca los DAO en una capa de servicio porque a medida que su aplicación se vuelve más complicada, hará cosas útiles y no triviales en el servicio. Por ejemplo, puede coordinar operaciones de datos complicadas con más de 1 DAO. Las capas de servicio también proporcionan límites de API que demarcan cuestiones transversales, como la gestión de transacciones, verificaciones de autorización, registro de rendimiento, etc.

Otra razón es bueno para abstraer su funcionalidad en servicios es que promueve componentes reutilizables y mantenibles. Cuando comiences, quizás te interese solo presentar algunos html. Usted escribe un servicio que carga algunos datos y maneja la parte html en la capa sobre la capa de servicio (capa de presentación). Ahora quiere poner de pie un servicio web RESTful. Su capa de servicio puede reutilizarse para cargar los datos; De lo único que tiene que preocuparse es de la json o xml que devuelve el punto final de su servicio web (y, por supuesto, la semántica REST).

Por lo tanto, para casos simples, la capa de Servicio podría agregar poco, pero a medida que su aplicación se expande, valen la pena e incluso es esencial para mantener el código limpio.

Answer 2

Sí, al principio parece que la capa de servicio no agrega mucho a la ecuación. Pero piénsalo así.

Capa de servicio = una capa entre su presentación y la capa de negocio.

Debe haber sido consciente de que siempre es bueno tener separación entre las capas. La capa de servicio puede asignarse a dominios de negocios distintos, capas de presentación, sin tener que preocuparse por cómo se usa la capa DOA.

Puede considerar esto como un límite entre otras dos capas, en este caso entre las capas de presentación y de negocios. El código en la capa de presentación típicamente implementa casos de uso. Un caso de uso típico es una secuencia de acciones realizadas por el usuario que resultan en interacciones entre uno o más objetos comerciales, flujos de trabajo y servicios. La capa de servicio le permite abstraer estas interacciones más pequeñas con una API intermedia, expuesta a través de servicios más gruesos. La capa de presentación hace una llamada a un servicio en la capa. El método de capa de servicio invocado coordinará los objetos y flujos de trabajo en la capa de negocio para implementar el comportamiento requerido.

problemas de seguridad

1. hago crear una capa de seguridad alrededor de las pilas de Servicio. Esto me ayudará a identificar la autenticidad del usuario y acceder al servicio dado.
2. También tengo una capa de transacción definida alrededor de la capa de servicio. Le dice al motor de la base de datos que confirme los cambios realizados en la capa de servicio, una vez que se devuelve después de ejecuciones exitosas.

Estas cosas también deben ser motivo de preocupación, si está definiendo capas de su aplicación.