Où dois-je faire l'injection avec Ninject 2+ (et comment dois-je organiser mes modules ?)

Question

J'ai une solution avec deux projets pertinents (pour cette question), et quelques autres ;

1. Bibliothèque de classes avec des fonctionnalités utilisées par plusieurs autres projets.
2. Application ASP.NET MVC.

Ma question est essentiellement de savoir où je dois faire IoC avec Ninject 2, en considérant...

• La bibliothèque de classes a besoin d'un peu d'amour DI, entre autres dans les classes de dépôt qui ont besoin d'objets de session spécifiques aux requêtes web (pensez à l'unité de travail).
• L'application MVC a besoin de DI car avec Ninject 2, vous héritez essentiellement de NinjectHttpApplication.
• Les tests unitaires de la bibliothèque de classes doivent en tenir compte pour injecter un ensemble différent de référentiels.
• Les tests unitaires pour l'application web doivent être injectés pour la même raison.

Je me suis mis dans un coin mental ici, parce que je ne voyais que trois options au départ. L'intégration dans la bibliothèque de classes, l'intégration dans l'application Web ou les deux, mais chacune pose des problèmes :

• Je ne peux pas faire de bricolage seulement dans la bibliothèque de classes puisque l'application MVC doit hériter de NinjectHttpApplication pour commencer.
• Je ne peux pas faire le DI uniquement dans l'application MVC - la bibliothèque de classes est utilisée par d'autres bibliothèques, après tout, et l'application MVC ne devrait pas en savoir trop sur les éléments internes de la bibliothèque de toute façon.
• Je suppose que c'est la seule issue que je vois : Un IoC indépendant pour les deux projets. La bibliothèque de classes et l'application MVC ont chacune leur propre configuration IoC et font de la DI pour leur matériel sans vraiment se soucier de l'autre.

Quelqu'un a-t-il des "meilleures pratiques" ou des directives sur la façon de faire quelque chose comme ça ? Je ne pense pas être la première personne à se retrouver dans cette situation, et il serait bon de savoir quelle est la "bonne" façon de procéder...

Merci !

Answer 1

Je ne connais pas NInject, mais à moins qu'il ne fonctionne de manière très différente de Windsor, StructureMap etc. les réponses tendent à rester les mêmes, car il y a des modèles communs de DI. En gardant cela à l'esprit :

La première chose à comprendre est que l'ID n'est pas liée à un cadre particulier tel que NInject ou Windsor. Il s'agit d'un ensemble de techniques et de modèles de conception à suivre. Vous pouvez faire de l'ID manuellement en utilisant ce que l'on appelle l'ID du pauvre, mais il est évident que cela devient bien meilleur avec un conteneur d'ID.

En quoi cela est-il pertinent ? C'est pertinent parce qu'une fois que vous avez réalisé cela, le corollaire est que la grande majorité du code de votre application devrait avoir pas de connaissance du conteneur DI que ce soit.

Alors, où utiliser le conteneur DI ? Il ne doit être utilisé que dans un Composition Racine qui, dans votre cas, correspondrait à Global.asax. Vous pouvez lire un peu plus sur ce sujet dans cette réponse SO - Bien que cette question porte sur Windsor, le principe reste le même.

Et vos tests unitaires, alors ? Ils devraient également ignorer complètement le conteneur DI. Voir cette autre réponse de SO pour plus de détails.

DI peut être réalisé dans votre bibliothèque avec une utilisation abondante de Injection de constructeur . Vous n'avez pas besoin de faire référence à un conteneur DI pour cela, mais cela vous facilite grandement la vie si vous utilisez un conteneur DI pour résoudre toutes les dépendances à partir de la racine de la composition.