dilemme de localisation des interfaces

Question

Étant donné un projet de code censé adhérer au principe SoC en implémentant des couches faiblement couplées, en disposant d'un conteneur IoC, etc., par exemple, une simple solution ASP.NET MVC qui est séparée en les assemblys suivants :

• Application assemblage+espace de noms
• Modèle assembly + espace de noms (contient un référentiel concret pour accéder aux données de base de données)

et où un dépôt en béton dans le Modèle l'assembly doit implémenter une interface commune IMyBusinessRepository, dans quel assembly mettriez-vous cette interface ?

1) Si vous mettez cette interface dans le Modèle assembly, il est probable qu'il serait impossible de remplacer cet assembly par un autre (du moins s'il a un espace de noms différent) sans modifier le code de l'assembly. Application assemblée.Aussi, une alternative IMyBusinessRepository l'implémentation résidant dans un assembly différent devrait faire référence à celle d'origine (Argh!)

2) Si vous le mettez dans le Application montage, il serait impossible d'utiliser le Modèle assemblage dans d'autres projets sans faire référence au Application assemblée (Argh!)

3) Ou créeriez-vous un assemblage commun distinct uniquement pour cette interface, et d'ailleurs, pour chaque interface commune ou ensemble d'interfaces ?(Argh ?)

Résumer, X l'assemblage doit être facilement remplaçable dans l'application UN (simplement en changeant une référence), et réutilisable dans les applications B, C, D.

Answer 1

Option 3.

Insérer les définitions d'interface avec le code appelant est correct jusqu'à ce que vous souhaitiez développer sur les interfaces mais pas sur le composant qui les contient (disons que vous souhaitez créer un fournisseur d'accès aux données mais que vous ne souhaitez pas extraire l'intégralité du site Web. projet).Le mettre avec une implémentation n'est qu'un discours fou :)

créeriez-vous un assemblage commun distinct uniquement pour cette interface et, d'ailleurs, pour chaque interface commune ou ensemble d'interfaces ?(Argh ?)

Je regrouperais les interfaces dans des assemblys séparés en pensant au Fermeture commune et Réutilisation commune des principes.En étant seuls, ils le seront également plus stable.Pensez aux scénarios dans lesquels ils seront utilisés - est-il logique de les garder ensemble - si c'est le cas, ils sont probablement OK dans un seul assemblage.

Answer 2

Vous pouvez simplement utiliser un assembly Contrats ou Interfaces, comme vous l'avez suggéré.

Cependant, étant donné que vous essayez de travailler avec le principe de séparation des préoccupations, envisagez-vous de remplacer toutes les implémentations de toutes vos interfaces en même temps, ou peut-être juste une seule implémentation concrète ici et là.

Si vous prévoyez de tout remplacer, un assembly séparé pourrait être préférable, sinon vous pouvez simplement l'implémentation de remplacement dans l'assembly Model aux côtés de l'implémentation existante et les interfaces sont également déclarées dans l'assembly Model.

Answer 3

Je recommanderais de placer les interfaces soit dans un assemblage séparé, soit à proximité de leur implémentation au sein du même assemblage.Il doit toujours y avoir au moins une implémentation de l'interface avec l'interface elle-même.L'approche courante consiste à placer les interfaces dans le même assembly, dans un dossier séparé.

Answer 4

SoC est un concept logique que vous essayez de traduire en un concept physique.

Le seul effet négatif de placer vos référentiels dans le modèle est l'assemblage, c'est qu'à l'avenir, il sera peut-être difficile d'échanger des assemblys.Je ne comprends pas ce souci ?Peut-être que des extraterrestres envahiront et que nous devrons mettre l'heure galactique dans nos bases de données.Devrions-nous coder cette abstraction maintenant ?Probablement pas.

Je ne comprends pas non plus le souci.Qu'est-ce qui t'empêche d'avoir Concrete1 : IRepository et Concrete2 : IRepository dans l'assemblage Modèles ?

De plus, vous couplez probablement quelque chose de manière incorrecte si le cœur de votre application doit être modifié par un changement dans vos classes Model.C'est un peu à l'envers.