Création d'une instance à l'aide de Ninject avec des paramètres supplémentaires dans le constructeur

Question

J'ai décidé de commencer à utiliser Ninject et je suis confronté à un problème. Disons que j'ai le scénario suivant. J'ai un IService et 2 classes implémentant cette interface. J'ai aussi une classe qui a un constructeur qui récupère IService et une classe qui implémente cette interface. int . Comment puis-je créer une instance de cette classe avec Ninject (je ne veux pas câbler cet int, je veux le passer à chaque fois que j'obtiens une instance) ?

Voici un code illustrant la situation :

interface IService
{
    void Func();
}

class StandardService : IService
{
    public void Func()
    {
        Console.WriteLine("Standard");
    }
}

class AlternativeService : IService
{
    public void Func()
    {
        Console.WriteLine("Alternative");
    }
}

class MyClass
{
    public MyClass(IService service, int i)
    {
        this.service = service;
    }

    public void Func()
    {
        service.Func();
    }

    IService service = null;
}
class Program
{
    static void Main(string[] args)
    {
        IKernel kernel = new StandardKernel(new InlineModule(
            x => x.Bind<IService>().To<AlternativeService>(),
            x => x.Bind<MyClass>().ToSelf()));

        IService service = kernel.Get<IService>();

        MyClass m = kernel.Get<MyClass>();
        m.Func();
    }
}

Answer 1

En With.ConstructorArgument existait dans la version 1.0 à cette fin. Dans la version 2.0, la syntaxe a légèrement changé :- With.Parameters.ConstructorArgument avec ninject 2.0

Véase Injecter une valeur dans une dépendance injectée pour plus de détails et d'exemples sur la manière d'utiliser le contexte, les fournisseurs et les arguments pour transmettre ce genre de choses plus correctement.

EDIT : Comme Steven a choisi de prétendre que mon commentaire n'est pas pertinent, je ferais mieux de clarifier ce que je dis avec quelques exemples (pour 2.0) :

MyClass m = kernel.Get<MyClass>( new ConstructorArgument( "i", 2) );

ce qui, à mes yeux, est très clair et indique exactement ce qui se passe.

Si vous êtes en mesure de déterminer le paramètre de manière plus globale, vous pouvez enregistrer un fournisseur et procéder de la manière suivante :

class MyClassProvider : SimpleProvider<MyClass>
{
    protected override MyClass CreateInstance( IContext context )
    {
        return new MyClass( context.Kernel.Get<IService>(), CalculateINow() );
    }
}

Et l'enregistrer comme suit :

x => x.Bind<MyClass>().ToProvider( new MyClassProvider() )

NB le CalculateINow() est l'endroit où vous insérez votre logique, comme dans la première réponse.

Ou plus complexe, comme ceci :

class MyClassProviderCustom : SimpleProvider<MyClass>
{
    readonly Func<int> _calculateINow;
    public MyClassProviderCustom( Func<int> calculateINow )
    {
        _calculateINow = calculateINow;
    }

    protected override MyClass CreateInstance( IContext context )
    {
        return new MyClass( context.Kernel.Get<IService>(), _calculateINow() );
    }
}

Vous l'enregistrerez de cette manière :

x => x.Bind<MyClass>().ToProvider( new MyClassProviderCustom( (  ) => new Random( ).Next( 9 ) ) )

MISE À JOUR : des mécanismes plus récents, qui présentent des schémas nettement améliorés avec moins de formalités que ceux décrits ci-dessus, sont incorporés dans le document Ninject.Extensions.Factory l'extension, voir : https://github.com/ninject/ninject.extensions.factory/wiki

Comme indiqué précédemment, si vous devez passer un paramètre différent à chaque fois et que vous avez plusieurs niveaux dans le graphe de dépendance, vous devrez peut-être faire quelque chose comme ceci .

Enfin, comme vous n'avez pas spécifié d'adresse de courrier électronique, il est possible que vous ne puissiez pas utiliser l'adresse de courrier électronique de votre choix. Using<Behavior> il va prendre par défaut la valeur spécifiée dans les options du noyau ( TransientBehavior dans l'exemple) qui pourrait rendre le fait que l'usine calcule le nombre d'heures de travail. i à la volée sans objet [par exemple, si l'objet était mis en cache].

Maintenant, je voudrais clarifier d'autres points des commentaires qui ont fait l'objet d'une confusion et qui ont été passés sous silence. Quelques éléments importants à prendre en compte concernant l'utilisation de l'ID, qu'il s'agisse de Ninject ou d'un autre système :

1. Faites en sorte que le plus de choses possibles soient faites par injection de constructeur afin de ne pas avoir à utiliser des attributs et des astuces spécifiques au conteneur. Il y a un bon article de blog à ce sujet appelé Votre conteneur IoC est affiché .

2. Minimiser le code qui va au conteneur et demande des choses - sinon votre code est couplé a) au conteneur spécifique (que la CSL peut minimiser) b) à la façon dont l'ensemble de votre projet est organisé. Il y a de bons articles de blog à ce sujet qui montrent que l'ASC ne fait pas ce que vous pensez qu'il fait. Ce sujet général est appelé Localisation des services et injection de dépendance . MISE À JOUR : voir http://blog.ploeh.dk/2011/07/28/CompositionRoot.aspx pour une justification détaillée et complète.

3. Minimiser l'utilisation de la statique et des singletons

4. Ne pensez pas qu'il n'existe qu'un seul conteneur [global] et qu'il est acceptable de le demander chaque fois que vous en avez besoin, comme une belle variable globale. L'utilisation correcte de modules multiples et de Bind.ToProvider() vous donne une structure pour gérer cela. De cette manière, chaque sous-système peut fonctionner de manière autonome et il n'y a pas de composants de bas niveau liés à des composants de haut niveau, etc.

Si quelqu'un veut compléter les liens vers les blogs auxquels je fais référence, j'en serais reconnaissant (ils sont tous déjà liés à d'autres articles sur SO, donc tout ceci n'est qu'une duplication que j'ai introduite dans le but d'éviter la confusion d'une réponse trompeuse).

Maintenant, si seulement Joel pouvait venir et me mettre au clair sur ce qu'est une belle syntaxe et/ou la bonne façon de faire !

MISE À JOUR : Bien que cette réponse soit manifestement utile au vu du nombre de votes positifs qu'elle a recueillis, j'aimerais faire les recommandations suivantes :

• Ce qui précède semble un peu dépassé et, pour être honnête, reflète beaucoup de réflexions incomplètes, ce qui est presque embarrassant depuis la lecture de ce document. Injection de dépendance dans .net - La première moitié est un traitement complet de tous les problèmes d'architecture qui l'entourent de la part d'un homme qui a passé beaucoup trop de temps ici à traîner autour de la balise d'injection de dépendance.
• Lire la suite Mark Seemann's top rated posts here on SO right now - vous apprendrez des techniques précieuses grâce à chacun d'entre eux