WCF SOA: Servicio de acceso a datos de CRUD ... ¿por qué molestarse (o nuestro diseño es incorrecto)?

Question

Tenemos un servicio de acceso a datos en nuestro sistema SOA WCF. Este servicio es responsable de realizar operaciones CRUD (crear, actualizar, eliminar) en tablas de bases de datos "de todo el sistema" y también es el origen de esta información para las consultas. Cualquier otro servicio en el sistema que desee acceder a las tablas bajo el control del DAS debe ir al DAS para obtenerlo o modificarlo. Usamos Entity Framework y construimos nuestro propio sistema de seguimiento de estado POCO para este DAS.

Tenemos otras tablas en nuestra base de datos que pertenecen a servicios individuales y almacenan datos solo para su propio uso, es decir, información de estado a la que pueden acceder si bloquean, reanudan o registran información comercial. Tenemos una regla a la que no se puede acceder a ninguna tabla por más de un servicio: por lo tanto, los datos que necesitan los servicios múltiples terminan en el DAS.

La verdad es que nunca he entendido por qué un servicio de acceso a datos es una buena idea en lugar de simplemente acceder a las tablas directamente. Parece ser más lento, nuestro DAS no es transaccional ya que no puede enviar un gráfico POCO para la actualización de la base de datos (solo un solo POCOS a la vez) y también tenemos problemas donde el DAS es realmente un cliente de otro servicio que necesita datos de ella ... dependencia circular.

¿Por qué molestarse con un DAS? ¿Por qué es un DAS tan importante cuando se trata de SOA? ¿Que me estoy perdiendo aqui? Único punto de control?

¿También es una falla de diseño de SOA que no todas las tablas son parte de un DAS y que algunos servicios tienen sus propias tablas "privadas"?

Cualquier discusión sobre esta bienvenida.

Answer 1

Tiene razón al pensar que esta es la forma correcta de hacer las cosas, y también tiene la certeza de que ralentiza las cosas y ocasionalmente puede ser engorroso. SOA necesariamente intercambia algo de eficiencia a cambio de garantizar puntos únicos de control para todos los datos asociados con un servicio. De hecho, incluso la idea de tener un servicio "común de DAS" es levemente mal en algunos círculos de SOA.

Al centralizar todas las operaciones de CRUD en un servicio en una aplicación SOA, puede garantizar la integridad de los datos y que las reglas de negocio se aplican correctamente. Para dar un ejemplo, piense en una entidad que le gustaría almacenar que tiene algunas reglas de negocios asociadas a ella que son difíciles de abordar desde una perspectiva pura de SQL, por ejemplo, digamos una tabla que almacena referencias de archivos, y crear/actualizar servicios que aseguran que estos archivos existen.

Con SOA y un único punto de acceso a esas tablas, puede codificar la lógica en los métodos de creación/actualización y tener la seguridad de que los datos que recibe del servicio son válidos, es decir, los archivos a los que se hace referencia. Si alguien fuera capaz de escribir en estas tablas o recuperar datos de ellas, no existiría esa seguridad, incluso si está llamando al servicio usted mismo, no sabe lo que otros programadores, a través de la malicia o simplemente el olvido del plan, olvidaron implementar esa regla crítica de negocios. Esto lleva a una programación defensiva en la que cada bit del código del cliente garantiza la lógica del negocio de forma independiente y, en última instancia, un enredo de lógica empresarial disperso por toda la aplicación.

Otro beneficio es la escalabilidad y facilidad de mantenimiento. Digamos que uno de sus servicios es acceder a una gran cantidad de datos. Con SOA, todo está "ennegrecido", por lo que su código de cliente no tiene mucho conocimiento de cómo se obtienen finalmente los datos. Puede cambiar su RDBMS, las tablas de particiones o implementar el almacenamiento en caché, y hacer que todo sea invisible para el código del cliente llamándolo, lo que garantiza que las actualizaciones dolorosas solo deban realizarse en un solo lugar. Con el código de la base de datos disperso en su aplicación, este tipo de actualización se vuelve extremadamente doloroso.