Acceso a datos de arquitectura SOA

Question

En mi arquitectura SOA, tengo varios servicios WCF.
Todos mis servicios necesitan acceder a la base de datos.

¿Debería crear un servicio especializado de WCF a cargo de todo el acceso a la base de datos?
¿O está bien si cada uno de mis servicios tiene su propio acceso a la base de datos?

En una versión, que tienen sólo una capa de entidad de instancia en un servicio, y todos los otros servicios dependen de este servicio.
En el otro, la capa Entidad es duplicada en cada uno de mis servicios.

El principal inconveniente de la primera versión es el acoplamiento inducido.
El inconveniente de la otra versión es la capa duplicación, y tal vez SOA mala práctica?

Entonces, ¿qué piensa la buena gente de Stack Overflow?

Answer 1

En mi opinión personal, si crea un servicio para todo el acceso a la base de datos, múltiples servicios dependen de UN servicio que de alguna manera vence al punto de SOA (es decir, los servicios son autónomos), como ha expresado. Cuando hablas de duplicación de capas, si cada servicio tiene sus propios datos para tratar, ¿realmente es una duplicación? Me doy cuenta de que probablemente tenga los mismos medios de interactuar con sus bases de datos relacionales o de los días de OOA que tenía una biblioteca de clases común que encapsulaba el acceso a los datos para usted. Esta es una de esas cosas con las que lucho, pero no veo ningún problema en que cada servicio tenga su propia capa de datos. De hecho, en Michele Bustamante's book (Capítulo 1 - Página 8), en realidad describe esto y agrega "Servicios encapsulan componentes comerciales y acceso a datos". Si nota que cada servicio tiene una capa DALC separada. Esta es una buena pregunta.

Answer 2

¿Por qué no utilizar simplemente un marco de inyección de dependencia y, si actualmente están utilizando la misma base de datos, simplemente permitirles compartir el mismo código, y si estuvieran en el mismo proyecto, todos usarían el mismo dll .

De esta manera, más adelante, si necesita poner algún código que no quiere que los demás compartan, puede hacer cambios y simplemente crear una nueva capa DAO.

Si hay un único singleton que todos usarán, entonces puede simplemente inyectarlo en cuando lo inyecte en la capa dao.

Pero, esto requerirá que usen el mismo controlador de marco DI.

Answer 3

Parece que tiene varios servicios pero una única base de datos.

Si esto es correcto, realmente no tiene una arquitectura SOA pura ya que los servicios no son independientes. (No hay nada de malo en no tener una arquitectura SOA pura, a menudo puede ser la elección correcta)

Agregar una capa WCF adicional simplemente complicaría y ralentizaría su solución.

Recomendaría que creara un único dll de acceso a datos que contenga todos los accesos a los datos y esté referenciado por cada servicio WCF. De esa manera no tienes ninguna duplicación de código. Como tiene una única base de datos, cualquier cambio en la base de datos/capa de datos requeriría una redistribución de todos los servicios en cualquier caso.

Answer 4

La verdadera victoria que trae SOA es que reduce el número de enlaces entre las aplicaciones.

En el pasado he trabajado con organizaciones que lo han hecho de diferentes maneras. Algunas capas de datos están integradas, y algunas están abstractas.

La forma más exitosa de hacerlo es cuando crea servicios genéricos de capa de datos para cada aplicación/base de datos y crea los servicios de nivel superior basados ​​en la capa de datos recién creada.