Ninject passer dans le constructeur de valeurs

Avec Ninject, comment voulez-vous configurer le noyau afin que je puisse définir ce constructeur valeurs ne sont que de passage dans l'instanciation d'un objet?

J'ai le texte suivant configurés dans un module:

Bind<IService1>()
    .To<Service1Impl>()
    .InSingletonScope()
    .Named("LIVE");
Bind<IService2>()
    .To<Service2Impl>()
    .InSingletonScope()
    .Named("LIVE")
    .WithConstructorArgument(
        "service1", 
        Kernel.Get<IService1>("LIVE"));

Service2Impl prend un paramètre dans le constructeur de IService1 mais je souhaite que cela à venir à partir du conteneur. Je veux aussi avoir nommé les liaisons que mon code sera ciblant les différentes versions au moment de l'exécution.

Cela semble fonctionner mais est-ce la bonne façon d'atteindre ce que je veux faire?
Dois-je être atteinte sans l'utilisation de nommé les liaisons et le câblage des différents modules de configuration dans le noyau?

MODIFIER

J'ai utilisé le ToMethod() une méthode pour spécifier un délégué pour appeler à la demande d'un type spécifique. Cela semble un peu plus sympa, je vais prendre le temps de compilation des avertissements si le constructeur de configuration est le mal plutôt que d'avoir à connaître le nom du paramètre que je suis passer en premier.

Grâce

OriginalL'auteur Tim Peel | 2011-05-19

  1. 16

    Je recommanderais le WithConstructorParameter surcharge qui prend un lambda comme suit:

    Bind<IService2>()
    .To<Service2Impl>()
    .InSingletonScope()
    .Named("LIVE")
    .WithConstructorArgument(
        "service1", 
        ctx => ctx.Kernel.Get<IService1>("LIVE"));

    Cela permettra de s'assurer que la résolution de IServive1 qui se passe au moment de l'activation de Service2Impl et pas au démarrage lorsque le conteneur est créé. Alors que dans votre cas, il n'a pas vraiment d'importance, comme Service1Impl est un singleton, il pourrait y avoir des effets secondaires sur le faire de la façon que vous avez initialement écrit:

    • La liaison de dépendance qui est injectée par WithConstructorArgument doit déjà exister. Cela implique que toutes les fixations sont de fait dans un ordre particulier. Cela crée peut se complique lorsqu'il y a plusieurs modules impliqués.

    • De délimitation de l'étendue des problèmes peuvent survenir lors de l'étendue personnalisée est utilisée. Ninject 2.0 introduit de cache et de recueillir gestion de la portée, de la liaison à une constante est très probablement à jeter que dans le désarroi.

    OriginalL'auteur

  2. 13

    J'ai utilisé ToMethod en fin de compte, ce qui m'a permis de construire le nécessaire instance avec les constructeurs afin de maintenir la compilation des erreurs.

    Par exemple:

    .ToMethod(Func<IContext, T> method)

Bind<IWeapon>().ToMethod(context => new Sword());
    Beaucoup préfèrent cette syntaxe .WithConstructorArgument, le compilateur détecte refactoring des erreurs. +1
    Avez-vous sérieusement avoir une application qui appelle pour une Arme de l'interface et l'Épée de l'objet?

    OriginalL'auteur

  3. 6

    Il semble que vous êtes en train de regarder dans le mauvais sens. Ninject va injecter de service 1 automatiquement en service de 2, si elle a comme argument du constructeur. Il n'y a pas besoin de WithConstructorArgument dans ce cas.

    S'il y a plusieurs IService1 vous devriez aller pour les conditions. E. g. WhenParentNamed(...)

    OriginalL'auteur

  4. 0

    Peut-être les Fournisseurs peuvent vous aider. Lier IService2 À un Prestataire. et dans la méthode Create de Fournisseur, l'utilisation du Noyau.Get("LIVE") pour créer le Service2Impl instance.

    voir le lien suivant pour savoir comment utiliser le Fournisseur de
    https://github.com/ninject/ninject/wiki/Providers%2C-Factory-Methods-and-the-Activation-Context

    Merci, j'ai vu qu'. Pensé qu'il était un peu trop de code et comme il est dit dans le lien que vous avez partagé le ToMethod est une version allégée d'un prestataire.

    OriginalL'auteur

  5. 0

    Je pense que ToConstant() est plus propre, les InSingletonScope est implicite:

    Bind<IService2>().ToConstant(new Service2Impl(argument)))
                 .Named("LIVE");

    OriginalL'auteur