Problème de conception de connexion dans Dapper, UoW, Référentiel générique et plusieurs bases de données

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

Question

J'essaie de construire une couche de référentiel pour une application qui interagit avec 3 bases de données, toutes MSSQL. J'ai fait la structure de référentiel basée sur Dapper et Unit Of Work Pattern et ressemble à ceci: Conception générique du repo

Est-ce un bon design? ou quoi de mieux pour cela?

Je ne veux pas passer l'instance de connexion de l'entreprise, car ce n'est pas le travail d'une couche de gestion; et devrait être de la couche de données elle-même. Actuellement, j'essaie de gérer la connexion dans la classe UnitOfWork avec le nom de la connexion et je voudrais la modifier.

EDIT: La conception n'est pas possible car elle a plusieurs héritages de classes, ce qui n'est pas possible dans c #. Y a-t-il des solutions alternatives?

Réponse populaire

Il y a très peu d'informations avec lesquelles travailler, mais je vais essayer. Peu importe le nombre de bases de données que vous utilisez ou leur type. Le dépôt avec UoW est un anti-pattern qui devient encore pire avec plusieurs dbs.

Un référentiel devrait fonctionner avec des concepts entiers (agrégats). Je vais sur la route DDD car c'est le moyen le plus simple de modéliser des choses dans une application. Un référentiel prendra en charge un type d'agrégat. Son implémentation utilisera dapper pour travailler avec la base de données.

Si vous devez modifier plusieurs agrégats en une seule opération, assurez-vous d'abord que le processus métier est correctement modélisé (ce n'est généralement pas le cas). Le processus métier lui-même est l'UoW, mais cela implique l'utilisation des événements de domaine et d'un bus de service durable (pour résister aux pannes de serveur). Et chaque gestionnaire de messages devrait être idempotent.

Un référentiel ne devrait jamais être au courant des autres repos et la partie héritage est principalement une conception douteuse. L'UoW à l' intérieur du repo qui permet la persistance de l'agrégat entier, quel que soit le nombre d'objets à partir desquels il est fabriqué, est la transaction db. Ne compliquez pas votre vie avec des transactions distribuées, gardez une transaction par base de données.

Cela étant dit, il est évident qu'une architecture correcte (qui a très peu à voir avec le modèle de référentiel, encore moins avec dapper) nécessite une personne ayant beaucoup d'expérience si vous voulez une base de code maintenable. Si vous êtes un junior, demandez à une personne âgée ou prenez le temps d'apprendre correctement la modélisation DDD. Il est très facile de trouver des «solutions» qui semblent simples, mais qui ne sont pas faciles à réparer.



Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi