L'Injection de dépendance avec les paramètres du constructeur qui ne sont pas des interfaces

Je suis encore un débutant à DI, et j'essaie de comprendre si je suis de penser à des choses de la mauvaise façon. Je suis en train de travailler sur un jouet problème lorsque je veux représenter un dé objet qui a une dépendance sur un IRandomProvider. L'interface est simple:

public interface IRandomProvider 
{
   int GetRandom(int lower, int upper);
}

Je veux avoir un dé constructeur qui ressemble à ceci:

Die(int numSides, IRandomProvider provider)

Je suis en train d'utiliser un statique DIFactory qui a une méthode comme ceci:

    public static T Resolve<T>()
    {
        if (kernel == null)
        {
            CreateKernel();
        }
        return kernel.Get<T>();
    }

Où CreateKernel simplement se lie à une mise en œuvre spécifique de IRandomProvider.

Je veux être en mesure d'appeler cette avec:

DIFactory.Resolve<Die>(20);

Je ne peux pas faire ce travail sans en faire une version spéciale de "Résoudre" ce qui peut me permettre de me traiter avec ConstructorArgs. Qui semble rendre les choses trop complexes, et m'obligerait à modifier DIFactory pour tous les autres cas, ainsi que de lier un nom spécifique pour le paramètre de constructeur.

Si je refactoriser le dé de la classe de ne pas utiliser l'int du constructeur, tout fonctionne bien. Mais maintenant que quelqu'un n'oubliez pas d'initialiser le numSides paramètre, ce qui semble une mauvaise idée, puisque c'est une exigence pour la classe.

Je suppose que c'est un mauvais modèle mental pour DI. Quelqu'un peut-il m'éclairer?

btw: N'êtes-vous pas sens Dice et pas Die? =)
Non, Mourir est singulier. dés est au pluriel. Je vais être mise en œuvre d'un Dé de la classe qui détient un certain nombre de filières, pouvez vérifier pour les doubles, etc.
J'ai parfois déplacer le paramètre à partir d'un constructeur à un membre de la fonction: int Rouleau(int numSides)

OriginalL'auteur Alex Kilpatrick | 2012-08-27

  1. 9

    Une inversion de contrôle conteneur n'est pas une usine. Ne pas l'utiliser pour résoudre des affaires objets comme votre Die classe. L'Inversion De Contrôle est utilisée pour laisser le conteneur de prendre le contrôle sur la durée de vie de vos objets. Un bonus est qu'il prend également en charge l'injection de dépendance modèle.

    Business objects est généralement créés, modifiés et supprimés. Donc pas besoin d'utiliser le conteneur pour eux. Et comme vous l'avez remarqué, ils prennent leurs paramètres obligatoires dans le constructeur, ce qui le rend difficile à utiliser le conteneur pour eux.

    Vous pouvez enregistrer un DieFactory dans le récipient et laisser prendre la IRandomProvider dans le constructeur:

    public class DieFactory
{
    public DieFactory(IRandomProvider provider)
    {}

    public Die Create(int numberOfSides)
    {
        return new Die(numberOfSides, _provider);
    }
}

    Mais il serait bien sûr préférable de créer une usine utilisée pour créer toutes les affaires liées aux objets. Ensuite, vous pouvez prendre le noyau comme une dépendance:

    public class AGoodNameFactory
{
    public DieFactory(IKernel kernel)
    {}

    public Die CreateDie(int numberOfSides)
    {
        var provider = _kernel.Resolve<IRandomProvider>();
        return new Die(numberOfSides, provider);
    }

    //other factories.
}

    Ou vous pouvez simplement prendre la IRandomProvider comme une dépendance directement dans la classe qui crée l' Die classe.

    C'est très intéressant. Pouvez-vous me dire l'avantage de cette approche sur Akim de la solution? Je viens de la vieille école OO, et il semble que dans votre approche vous seulement de produire des objets par l'intermédiaire des usines? Est-il jamais un moment où vous n'utilisez pas une usine à créer un objet?
    Pas pour de simples entités non. a mon avis le conteneur ne doit être utilisé pour produire des services et des catégories similaires. c'est à dire les classes qui prend une ou plusieurs entités (comme Die et d'appliquer un peu de logique).
    +1 et je vais vous parler de Ninject.Extensions.Usine

    OriginalL'auteur jgauffin

  2. 5

    Vous pouvez utiliser ConstructorArgument avec Kernel.Get dans cette situation particulière.
    Voici totalité de l'échantillon.

    De configuration du Module

    public class ExampleKernel : NinjectModule
{
    public override void Load()
    {
        Bind<IRandomProvider>()
            .To<RandomProvider>();

        Bind<Die>()
            .ToSelf()
            .WithConstructorArgument("numSides", 6);
                           // default value for numSides
    }
}

    Résoudre dans le code

    var d6 = kernel.Get<Die>(); //default numSides value
var d20 = kernel.Get<Die>(new ConstructorArgument("numSides", 20)); //custom numSides

Assert.That(d6.NumSides == 6);
Assert.That(d20.NumSides == 20);
    Merci pour le détail de la solution. De La Liaison.ToSelf jamais fait sens pour moi, mais maintenant, il est très clair.
    C'est une belle réponse claire, mais ne sommes-nous pas maintenant de retour avec l'OP problème "maintenant que quelqu'un n'oubliez pas d'initialiser le numSides paramètre, ce qui semble une mauvaise idée, puisque c'est une exigence pour la classe" ?

    OriginalL'auteur Akim