Quelle est l'intention des modules ninject?

Question

Je suis un débutant complet à ninject

J'ai à part quelqu'un d'tirais autre code et trouvé plusieurs instances de modules ninject -. Les classes qui dérivent de Ninject.Modules.Module, et ont une méthode de charge qui contient la majeure partie de leur code

Ces classes sont appelées en invoquant la méthode LoadModule d'une instance de StandardKernel et passer une instance de la classe du module.

Peut-être que je manque quelque chose d'évident, mais quel est l'avantage de ce sur la simple création d'une plaine ancienne classe et appelant sa méthode, ou peut-être une classe statique avec une méthode statique?

Answer 1

Les modules Ninject sont des outils utilisés pour enregistrer les différents types avec le conteneur IoC. L'avantage est que ces modules sont ensuite conservés dans leurs propres classes. Cela vous permet de mettre différents niveaux / services dans leurs propres modules.

// some method early in your app's life cycle
public Kernel BuildKernel()
{
    var modules = new INinjectModule[] 
    {
        new LinqToSqlDataContextModule(), // just my L2S binding
        new WebModule(),
        new EventRegistrationModule()
    };
    return new StandardKernel(modules);
}

// in LinqToSqlDataContextModule.cs
public class LinqToSqlDataContextModule : NinjectModule
{
    public override void Load()
    {
        Bind<IRepository>().To<LinqToSqlRepository>();
    }
}

Avoir plusieurs modules permet une séparation des préoccupations, même à l'intérieur de votre conteneur IoC.

Le reste de vous la question sonne comme il est plus sur et DI IoC dans son ensemble, et pas seulement Ninject. Oui, vous pouvez utiliser des objets de configuration statiques pour faire à peu près tout ce qu'un conteneur IoC fait. conteneurs IoC deviennent vraiment agréable quand vous avez plusieurs hiérarchies de dépendances.

public interface IInterfaceA {}
public interface IInterfaceB {}
public interface IInterfaceC {}

public class ClassA : IInterfaceA {}

public class ClassB : IInterfaceB
{
    public ClassB(IInterfaceA a){}
}

public class ClassC : IInterfaceC
{
    public ClassC(IInterfaceB b){}
}

Construction ClassC est une douleur à ce stade, avec de multiples profondeurs d'interfaces. Il est beaucoup plus facile de simplement demander le noyau pour un IInterfaceC.

var newc = ApplicationScope.Kernel.Get<IInterfaceC>();

Answer 2

  

Peut-être que je manque quelque chose évidente   , mais quel est l'avantage de cette   sur la simple création d'une plaine ancienne classe   et appelant sa méthode, ou peut-être un   classe statique avec une méthode statique?

Oui, vous pouvez simplement appeler un tas de déclarations de Bind<X>().To<Z>() pour configurer les liaisons, sans module.

La différence est que si vous mettez ces déclarations dans un module puis:

• IKernel.Load(IEnumerable<Assembly>) peut découvrir de façon dynamique ces modules à travers la réflexion et de les charger.
• les liaisons sont logiquement regroupées sous un nom; vous pouvez utiliser ce nom pour les décharger à nouveau avec IKernel.Unload(string)

Answer 3

  

Peut-être que je manque quelque chose d'évident, mais quel est l'avantage de ce sur la simple création d'une plaine ancienne classe et appelant sa méthode, ou peut-être une classe statique avec une méthode statique?

Pour nous, il est la possibilité d'ajouter des tests à un moment ultérieur très facilement. Il suffit de remplacer quelques liaisons avec mockobjects et le tour est joué ..... sur le code existant sans DI qui câblé « tout » en place, il est presque impossible de commencer à insérer des cas de test sans être retravaillées. Avec un DI en place et aussi longtemps qu'il a été utilisé correctement où le tout câblé DI en place, il est très simple de le faire même le code existant qui peut être très laid.

Dans de nombreux cadres de DI, vous pouvez utiliser le module de production pour votre test avec un module de test qui remplace les liaisons spécifiques avec mockobjects (en laissant le reste du câblage en place). Ceux-ci peuvent être des tests de système plus que les tests unitaires, mais je tendance à préférer des tests de niveau plus élevé que le développeur moyen car il teste l'intégration entre les classes et il est grand documentation pour quelqu'un qui se joint au projet et peut voir la fonctionnalité tout en action (au lieu de juste une partie de la fonction) sans avoir à installer un système entier).