Emplacement des interfaces dans la solution Visual Studio

Question

Quelle est la meilleure pratique en ce qui concerne la mise en place de Interface types. Souvent, le plus rapide et le plus simple est de placer l'interface dans le même projet que les instances concrètes. Cependant, si je comprends bien les choses, cela signifie que vous êtes plus susceptible de vous retrouver avec des problèmes de dépendance. Est-ce une évaluation juste de la situation et si oui, cela signifie-t-il que les interfaces devraient être séparées en différents projets?

Answer 1

Cela dépend de ce que vous voulez faire. Vous avez raison de dire que le fait de placer des interfaces et des classes dans le même assemblage limitera quelque peu l'utilité de l'abstraction desdites interfaces. Par exemple. Si vous souhaitez charger des types dans un AppDomain dans le but de les décharger à nouveau, vous accéderez généralement aux instances via les interfaces. Cependant, si les interfaces et les classes se trouvent dans le même assemblage, vous ne pouvez pas charger les interfaces sans charger les classes. De même, si vous voulez fournir un ensemble différent de classes pour une ou plusieurs interfaces, vous obtiendrez toujours tous les anciens types s'ils se trouvent dans le même assemblage que les interfaces. Cela dit, je dois admettre que je place des interfaces et des classes dans le même assemblage de temps en temps simplement parce que je ne pense pas que j'aurai besoin de la flexibilité, donc je préfère garder les choses simples. Tant que vous avez la possibilité de tout reconstruire, vous pouvez réorganiser les interfaces plus tard si le besoin s'en fait sentir.

Answer 2

Dans une solution simple, je peux avoir des interfaces publiques et des classes de fabrique publiques, ainsi que des classes d'implémentation internes, toutes dans le même projet. Dans une solution plus compliquée, alors pour éviter que le projet A ne dépende des interfaces du projet B, et que le projet B dépende des interfaces définies dans le projet A, je pourrais déplacer les interfaces dans un projet distinct qui dépend lui-même sur rien et dont tous les autres projets peuvent dépendre. Je pratique "les grands systèmes ne peuvent pas être créés à partir de rien: les grands systèmes qui fonctionnent sont invariables et ont évolué à partir de petits systèmes qui fonctionnaient". Je pourrais donc commencer par une solution petite et simple avec les interfaces dans le même projet que l'implémentation, puis plus tard (si et quand cela s'avère nécessaire) refactoriser cela pour déplacer les interfaces dans un ensemble séparé.

Là encore, il y a l'emballage; vous pouvez développer des projets séparés et reconditionner tout en un seul assemblage lorsque vous l'expédiez.

Answer 3

Il s'agit d'un détail de déploiement. Il y a quelques cas où vous avez pour mettre un type d'interface dans son propre assembly. Certainement lors de leur utilisation dans le développement de plug-ins ou tout autre type de code qui s'exécute dans plusieurs AppDomains. Presque définitivement quand Remoting ou tout autre type d'architecture connectée.

Au-delà, cela n'a plus tellement d'importance. Un type d'interface est comme une autre classe, vous pouvez ajouter une référence d'assemblage si vous en avez besoin dans un autre projet. Les garder séparés peut aider à contrôler le versionnement. C'est une bonne idée de les garder séparés si une modification d'un type d'interface peut entraîner des changements étendus dans les classes qui les implémentent. Le fait de modifier [AssemblyVersion] lorsque vous le faites maintenant permet de résoudre les problèmes de déploiement dans lesquels vous avez oublié de mettre à jour un assembly client.