L'architecture des modules de NInject me semble utile, mais je crains que cela ne soit un peu en désordre.Comment organisez-vous vos modules NInject?
Comment organisez-vous vos modules? Dans quel assemblage les gardez-vous et comment décidez-vous quels câblages vont dans quel module?
Chaque sous-système obtient un module. Bien sûr, la définition de ce qui justifie la catégorisation comme un « sous-système » dépend ...
Dans certains cas, la responsabilité de certaines liaisons est poussé à un niveau plus élevé comme un sous-système de niveau inférieur/composant n'est pas en mesure de prendre une décision finale définitive - dans certains cas, cela peut être réalisé en passant des paramètres dans le module.
Répondre à mon propre message après quelques années d'utilisation de NInject.
Voici comment organiser mes NInjectModules, en utilisant un magasin livre comme exemple:
Ce que cela dit est que chaque projet dans le système vient préemballé avec un ou plusieurs Des modules NInject qui savent comment configurer les liaisons pour les classes de ce projet.
La plupart du temps, une application individuelle ne veut pas apporter de modifications importantes aux modules d'injection par défaut fournis par un projet. Par exemple, si je crée une petite application WinForm qui doit importer le projet DataAccess, normalement, je souhaite également que toutes les classes du Repository < du projet soient liées à leurs interfaces IRepository < associées.
En même temps, rien n'oblige une application individuelle à utiliser un module d'injection particulier.Une application peut créer son propre module d'injection et ignorer les modules par défaut fournis par un projet qu'elle importe. De cette manière, le système reste flexible et découplé.
Donc ... cela signifie que vous devez inclure un paquet/une référence Ninject dans chacun des projets qui ont un module ??? Je préférerais avoir un seul endroit dans mon assembly d'appelant (par exemple, le projet web) où j'inscris tous les services dont j'ai besoin, et alors seulement cet assembly prendra une référence directe à Ninject. Pensées? –
Oui c'est un inconvénient avec cette configuration. Cependant, sauf si vous avez une application très pure qui n'utilise jamais l'injection de propriété ou utilise Kernel.Get <>() alors je me retrouve généralement avec une référence NInject de toute façon. – cbp
Eh bien ... Je viens de terminer un projet qui utilisait Unity for DI, et je me suis retrouvé avec une longue méthode RegisterServices dans mon bootstrapper dans le projet web. Aucun de mes projets libs de classe avait une dépendance directe sur Unity ou EntLib directement. Ils ont tous tiré parti de l'injection du constructeur. Je pensais que c'était plutôt sympa. –
Bonne question. J'aimerais voir plus de discussions à ce sujet car je partage vos préoccupations. Avoir un module par sous-système semble raisonnable, mais j'ai aussi des modules pour le câblage des dépendances différemment pour le test unitaire. – JulianM