Problema de diseño de conexión en Dapper, UoW, Generic Repository y múltiples bases de datos

c# dapper multiple-databases repository-pattern unit-of-work

Pregunta

Estoy intentando construir una capa de repositorio para una aplicación que interactúa con 3 bases de datos, todas MSSQL. Hice que la estructura del repositorio se basa en Dapper y Unit Of Work Pattern y se ve a continuación: Diseño Repo genérico

¿Es este un buen diseño? o ¿qué podría ser un mejor diseño para esto?

No quiero pasar la instancia de conexión de la empresa, ya que no es el trabajo de una capa de negocios; y debe ser de la capa de datos en sí. Actualmente, intento administrar la conexión dentro de la clase UnitOfWork con el nombre de la conexión y me gustaría cambiarla.

EDITAR: El diseño no es posible ya que tiene herencia de clase múltiple, lo cual no es posible en c #. ¿Hay alguna solución alternativa?

Respuesta popular

Aquí hay muy poca información para trabajar, pero lo intentaré. No importa cuántos db estés usando o su tipo. El repositorio con UoW es un patrón anti que se vuelve aún peor con múltiples dbs.

Un repositorio debería funcionar con conceptos completos (agregados). Voy por la ruta DDD porque es la forma más fácil de modelar cosas en una aplicación. Un repositorio se ocupará de un tipo agregado. Su implementación usará dapper para trabajar con el db.

Si necesita modificar múltiples agregados en una operación, primero asegúrese de que el proceso de negocios esté modelado correctamente (generalmente no es así). El proceso de negocio en sí es el UOW, pero esto implica el uso de eventos de dominio y un bus de servicio duradero (para ser resistente al bloqueo del servidor). Y cada controlador de mensajes debe ser idempotente.

Un repositorio nunca debe saber acerca de otros repositorios y la parte de herencia es principalmente un diseño dudoso. La UoW dentro del repositorio que permite la persistencia de todo el agregado independientemente de la cantidad de objetos a partir de los cuales está hecha, es la transacción db. No compliques tu vida con transacciones distribuidas, mantén una transacción por db.

Dicho esto, es obvio que una arquitectura adecuada (tiene muy poco que ver con el patrón del repositorio, incluso menos con el atildado) necesita a alguien con mucha experiencia si desea una base de código que pueda mantenerse. Si eres un junior, pregúntale a un senior o tómate un tiempo para aprender a modelar DDD correctamente. Es muy fácil encontrar 'soluciones' que parecen simples pero que son un desastre imposible de mantener.



Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
¿Es esto KB legal? Sí, aprende por qué
Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
¿Es esto KB legal? Sí, aprende por qué