L'Injection de dépendance vs Emplacement de Service

Service Locator est un anti-modèle, pour des raisons parfaitement décrit à http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx. En termes de connexion, vous pouvez considérer que comme une dépendance tout comme les autres, et de les injecter une abstraction par le constructeur ou des biens de l'injection.

La seule différence avec log4net, est qu'il nécessite que le type de l'appelant qui utilise le service. À l'aide de Ninject (ou tout autre contenant) Comment puis-je trouver le type qui demande le service? décrit comment vous pouvez résoudre ce problème (il utilise Ninject, mais est applicable à tout conteneur IoC).

Sinon, vous pourriez penser à l'enregistrement de manière transversale préoccupation, qui n'est pas appropriée à mélanger avec votre code de la logique métier, dans ce cas vous pouvez utiliser l'interception qui est fourni par de nombreux Cio conteneurs. http://msdn.microsoft.com/en-us/library/ff647107.aspx décrit à l'aide de l'interception à l'Unité.

Parfois de journalisation peut être mis en œuvre à l'aide de AOP, de sorte qu'il ne se mélange pas avec la logique métier.

Autrement, les options sont :

• utiliser un dépendance optionnelle (comme le setter de la propriété), et de l'unité de test à ne pas injecter tout enregistreur. Conteneur IOC prend soin de réglage automatiquement pour vous si vous exécutez dans la production.
• Lorsque vous avez une dépendance presque tous les objets de votre application à l'aide ("logger" objet le plus voir exemple), il est l'un des rares cas où le singleton anti-modèle devient une bonne pratique. Certaines personnes appellent cela de la "bonne singletons" un Ambiante Contexte:
  http://aabs.wordpress.com/2007/12/31/the-ambient-context-design-pattern-in-net/

Bien sûr, ce contexte doit être configurable, de sorte que vous pouvez utiliser stub/maquette pour les tests unitaires.
D'autres ont suggéré l'utilisation de AmbientContext, est de mettre la Date/Heure actuelle du fournisseur , de sorte que vous pouvez stub cours de test unitaire, et accélère le temps si vous le souhaitez.

Nous avons atterri sur un compromis: l'utilisation DI mais bundle de haut niveau de la dépendance à un objet en évitant de refactoring de l'enfer les dépendances de changement.

Dans l'exemple ci-dessous, nous pouvons ajouter à 'ServiceDependencies", sans avoir à refactoriser tous les dérivés de dépendances.

Exemple:

public ServiceDependencies{
     public ILogger Logger{get; private set;}
     public ServiceDependencies(ILogger logger){
          this.Logger = logger;
     }
}

public abstract class BaseService{
     public ILogger Logger{get; private set;}

     public BaseService(ServiceDependencies dependencies){
          this.Logger = dependencies.Logger; //don't expose 'dependencies'
     }
}


public class DerivedService(ServiceDependencies dependencies,
                              ISomeOtherDependencyOnlyUsedByThisService                       additionalDependency) 
 : base(dependencies){
//set local dependencies here.
}

Je sais que cette question est un peu vieux, j'ai juste pensé que je voudrais donner à mon entrée.

En réalité, 9 fois sur 10, vous n'avez pas vraiment besoin SL et devrait s'appuyer sur DI. Cependant, il y a certains cas où vous devriez utiliser SL. Un domaine que je trouve moi-même à l'aide de SL (ou une variante, celle-ci) est dans le développement de jeux.

Un autre avantage de SL (à mon avis) est la possibilité de passer autour de internal classes.

Ci-dessous est un exemple:

internal sealed class SomeClass : ISomeClass
{
    internal SomeClass()
    {
        //Add the service to the locator
        ServiceLocator.Instance.AddService<ISomeClass>(this);
    }

    //Maybe remove of service within finalizer or dispose method if needed.

    internal void SomeMethod()
    {
        Console.WriteLine("The user of my library doesn't know I'm doing this, let's keep it a secret");
    }
}

public sealed class SomeOtherClass
{
    private ISomeClass someClass;

    public SomeOtherClass()
    {
        //Get the service and call a method
        someClass = ServiceLocator.Instance.GetService<ISomeClass>();
        someClass.SomeMethod();
    }
}

Comme vous pouvez le voir, l'utilisateur de la bibliothèque n'a aucune idée de cette méthode a été appelée, parce que nous n'avons pas DI, non pas que nous serions en mesure de toute façon.

Je sais que les gens sont vraiment dire DI est la seule bonne CIO motif, mais je n'ai pas cette. Je vais essayer de vendre SL un peu. Je vais utiliser la nouvelle MVC framework pour vous montrer ce que je veux dire. Premier DI moteurs sont vraiment complexe. Ce que les gens vraiment dire quand ils disent DI, est d'utiliser un cadre de travail comme Unité, Ninject Autofac... que faire tout le levage lourd pour vous, où SL peut être aussi simple que de faire une usine de classe. Pour un petit rapide de ce projet est un moyen facile de faire du CIO, sans apprentissage tout un cadre pour une bonne DI, ils pourraient ne pas être si difficile à apprendre, mais encore.
Maintenant pour le problème que DI peut devenir. Je vais utiliser une citation de MVC Core docs.
"ASP.NET Core est conçu à partir du sol jusqu'à l'appui et à tirer parti de l'injection de dépendance." La plupart des gens disent que sur DI "les 99% de votre base de code devrait avoir aucune connaissance de votre conteneur IoC." Alors, pourquoi auraient-ils besoin de conception de sol si seulement 1% de code devrait être conscient, n'est-ce pas vieux MVC soutien DI? Eh bien c'est le grand problème de la DI cela dépend de DI. Tout en faisant travailler "COMME IL faut le FAIRE" prend beaucoup de travail. Si vous regardez la nouvelle Action d'Injection n'est-ce pas en fonction de DI si vous utilisez [FromServices] attribut. Maintenant DI les gens vont dire NON, vous sont censés pour aller avec les Usines pas ce genre de choses, mais comme vous pouvez le voir, pas même les gens faisant MVC fait droit. Le problème de la DI est visible dans les Filtres ainsi, regardez ce que vous devez faire pour obtenir des DI dans un filtre

public class SampleActionFilterAttribute : TypeFilterAttribute
{
    public SampleActionFilterAttribute():base(typeof(SampleActionFilterImpl))
    {
    }

    private class SampleActionFilterImpl : IActionFilter
    {
        private readonly ILogger _logger;
        public SampleActionFilterImpl(ILoggerFactory loggerFactory)
        {
            _logger = loggerFactory.CreateLogger<SampleActionFilterAttribute>();
        }

        public void OnActionExecuting(ActionExecutingContext context)
        {
            _logger.LogInformation("Business action starting...");
            //perform some business logic work

        }

        public void OnActionExecuted(ActionExecutedContext context)
        {
            //perform some business logic work
            _logger.LogInformation("Business action completed.");
        }
    }
}

Où, si vous avez utilisé SL vous pourriez avoir fait cela avec var _logger = Localisateur.Get();. Et puis nous arrivons à la Vue. Avec tous il y a de la bonne volonté concernant DI ils avaient à utiliser SL pour la vue. la nouvelle syntaxe @inject StatisticsService StatsService est le même que var StatsService = Locator.Get<StatisticsService>();.
La plupart annoncés partie de la DI est le test unitaire. Mais ce que les gens et de faire est tout simplement de le tester, il se moquer de services n'ayant pas de but ou d'avoir à câbler il DI moteur pour faire des tests réels. Et je sais que vous pouvez faire quelque chose de mal, mais les gens finissent par faire un SL localisateur même si ils ne savent pas ce que c'est. Où beaucoup de gens font des DI sans jamais de lire sur elle d'abord.
Mon plus gros problème avec le DI est que l'utilisateur de la classe doit être au courant du fonctionnement interne de la classe dans d'autres de l'utiliser.

SL peut être utilisé de la bonne manière et a quelques avantages en plus de sa simplicité.