J'essaie de réajuster (mauvaise idée je sais, mais mieux vaut tard que jamais) IOC et DI dans une solution existante.IOC à travers des projets de studios visuels?
La base de code est constituée d'environ 30 projets, chacun ayant des classes qui ont peu ou pas de visibilité sur le monde extérieur. Étant relativement nouveau à la chose IOC j'essaie d'utiliser les meilleures pratiques lors du remaniement du code, et il semble préférable de ne pas passer le conteneur IOC ou le rendre statique, d'où je tente de tout faire via injection de constructeur.
Cependant, et voici ma question, je dois faire énormément de classes publiques à travers les projets (c'est-à-dire les fichiers physiques .csproj). Je dois le faire parce que mon 'module de configuration' (j'utilise Ninject, mais c'est une question agnostique du CIO) a besoin de savoir tout sur n'importe quelle classe dans n'importe quel projet afin de pouvoir résoudre les dépendances.
Ai-je manqué quelque chose d'important? Est-ce que toutes mes classes sont censées être publiques si elles sont basées sur une interface? Puis-je en quelque sorte créer un conteneur IOC pour chacune de mes limites csproj et que faire l'injection pour moi?
Ta
Pour: Encapsulation. Inconvénients: Chaque module a maintenant une dépendance sur Ninject; la configuration peut être plus rigide (et si le consommateur A veut IFoo être implémenté par Bar au lieu de Foo?); pas un seul endroit pour voir toutes les cartographies. – TrueWill