Injection de dépendances: comment intégrer les valeurs reçues des paramètres de méthode dans les dépendances que je souhaite résoudre en tant que paramètres de constructeur?

Réponse n ° 2 - Passez les paramètres si nécessaire

Cette solution abandonne la prémisse originale selon laquelle nous pouvons convertir avec succès un paramètre de méthode en paramètre de constructeur. Au lieu de cela, il suppose que le repoName (ou un différenciateur équivalent) devra être passé dans toute fonction qui nécessite ces informations. Voici un exemple d'implémentation possible du contrôleur (notez que BusinessLogic nécessite désormais un paramètre supplémentaire):

public class BusinessLogic : IBusinessLogic
{
    private readonly IRepositoryResolver repositoryResolver;

    public BusinessLogic(IRepository repositoryResolver)
    {
        this.repositoryResolver = repositoryResolver;
    }

    public string[] Compute(string repoName)
    {
        var repo = repositoryResolver.Resolve(repoName);
        return repo.Get();
    }
}

Et voici la nouvelle implémentation de BusinessLogic :

public class ParameterPassingController : ApiController
{
    private readonly IBusinessLogic businessLogic;

    public ParameterPassingController(
        IBusinessLogic businessLogic)
    {
        this.businessLogic = businessLogic;
    }

    public IEnumerable<string> Get(string repoName)
    {
        return businessLogic.Compute(repoName);
    }
}

Cette solution semble très gênante car elle modifie la classe BusinessLogic pour qu'elle dépende d'un objet moins direct qu'auparavant. Les dépendances d'une classe doivent être déterminées par la classe et non par les besoins de l'appelant. La classe BusinessLogic était meilleure qu'avant, et toute solution qui nous oblige à la compliquer n'est probablement pas la bonne.

Réponse n ° 3 - Introduire des résolveurs supplémentaires

Cette solution ajoute un BUSINESS LOGIC RESOLVER, en utilisant le même modèle que le REPOSITORY RESOLVER. (Modèle d'usine?)

public class BusinessLogicResolverController : ApiController
{
    private readonly IRepositoryResolver repoSource;
    private readonly IBusinessLogicResolver businessLogicSource;

    public BusinessLogicResolverController(
        IRepositoryResolver repoSource,
        IBusinessLogicResolver businessLogicSource)
    {
        this.repoSource = repoSource;
        this.businessLogicSource = businessLogicSource;
    }

    public IEnumerable<string> Get(string repoName)
    {
        var repo = repoSource.Resolve(repoName);
        var businessLogic = businessLogicSource.Resolve(repo);
        return businessLogic.Compute();
    }
}

Ce que je n'aime pas à ce sujet, c'est que s'il y a beaucoup de classes qui dépendent d'un seul IRepository (et dans mon exemple non trivial, il y en a beaucoup), je dois créer un résolveur pour chacune d'elles. Cela complique également d'autres choses que les conteneurs DI peuvent aider, comme les applications de décorateur et autres.

Réponse # 4 - Introduire le couplage temporel

Cette solution remplace l'implémentation enregistrée d'IRepository par une classe qui implémente également IRepositoryManager, lui permettant d'être pointé vers le référentiel approprié au moment de l'exécution. Voici à quoi ressemble le contrôleur maintenant:

        repoManager.Set(repoName);
        return businessLogic.Compute();
        

... et voici l'implémentation d'IRepositoryManager:

public class RepositoryManager : IRepositoryManager, IRepository
{
    private readonly IRepositoryResolver resolver;
    private IRepository repo = null;

    public RepositoryManager(IRepositoryResolver resolver)
    {
        this.resolver = resolver;
    }

    void IRepositoryManager.Set(string repoName)
    {
        this.repo = resolver.Resolve(repoName);
    }

    string[] IRepository.Get()
    {
        if (repo == null)
            throw new InvalidOperationException($"{nameof(IRepositoryManager.Set)} must be called first.");
        else
            return repo.Get();
    }
}

Cette solution permet certainement au contrôleur de rester petit, mais d'après mon expérience, le couplage temporel fait presque toujours plus mal que cela n'aide. De plus, il n'est pas clair que ces deux lignes du contrôleur aient quelque chose à voir l'une avec l'autre:

public class TemporallyCoupledController : ApiController
{
    private readonly IRepositoryManager repoManager;
    private readonly IBusinessLogic businessLogic;

    public TemporallyCoupledController(
        IRepositoryManager repoManager,
        IBusinessLogic businessLogic)
    {
        this.repoManager = repoManager;
        this.businessLogic = businessLogic;
    }

    public IEnumerable<string> Get(string repoName)
    {
        repoManager.Set(repoName);
        return businessLogic.Compute();
    }
}

... mais évidemment ils le font. C'est donc une très mauvaise solution.

Réponse n ° 5 - Injectez la dépendance basée sur les paramètres à l'intérieur du contrôleur

Cette solution fait du contrôleur une partie de la racine de la composition, plutôt que de le résoudre par injection de dépendances. (La ligne où le conteneur construit est récupéré peut être effectuée d'une autre manière, mais ce n'est pas la partie importante - l'idée principale est que nous devons accéder à sa méthode BeginLifetimeScope directement après avoir les paramètres d'entrée.)

public class SelfAwareDIController : ApiController
{
    public SelfAwareDIController() { }

    public IEnumerable<string> Get(string repoName)
    {
        var container = (AutofacWebApiDependencyResolver)GlobalConfiguration.Configuration.DependencyResolver;

        using (var scope = container.Container.BeginLifetimeScope(builder =>
            builder.RegisterInstance(new Input { RepoName = repoName }).AsSelf()))
        {
            var businessLogic = scope.Resolve<IBusinessLogic>();
            return businessLogic.Compute();
        }
    }
}

Cette solution évite le couplage temporel (puisque businessLogic ne peut pas exister en dehors de la durée de vie où il peut être résolu). Cela nous permet également de supprimer le REPOSITORY RESOLVER; J'étais déjà mal à l'aise avec REPOSITORY RESOLVER car c'est une extension de la racine de composition qui interfère avec la gestion centralisée de la création d'objets par le conteneur DI. Un inconvénient est qu'il déplace une partie du code lié au conteneur dans le contrôleur plutôt que de tout garder dans la configuration du service. (Encore une fois, dans un exemple non trivial, il peut y avoir de nombreux contrôleurs qui doivent implémenter une logique similaire.) Cela empêche également le contrôleur lui-même d'être instancié par le conteneur DI (ce que vous pouvez faire avec le package AutoFac.WebApi2 ). Pourtant, parce que cela restreint la connaissance de ce nouveau contexte au contrôleur (et supprime la nécessité d'avoir une classe d'usine), c'est probablement la moins répréhensible des solutions que j'ai identifiées.

Encore une autre possibilité - transmettre IBusinessLogic au Controller non pas en tant qu'instance, mais en tant qu'usine (c'est-à-dire Func <string, IBusinessLogic>) et dans l'usine Methode Compute Fall avec repoName. Voir, par exemple: https://autofaccn.readthedocs.io/en/latest/advanced/delegate-factories.html