Внедрение зависимостей и расположение службы

Поскольку класс теперь внедряется с контейнером IoC, почему бы не использовать его также для разрешения всех других зависимостей?

Использование шаблона локатора сервисов полностью устраняет один из основных моментов внедрения зависимостей. Смысл внедрения зависимостей - сделать зависимости явными. Как только вы скроете эти зависимости, не сделав их явными параметрами в конструкторе, вы больше не будете выполнять полноценную инъекцию зависимостей.

Все это конструкторы для класса с именем Foo (настроенного на тему песни Johnny Cash):

Неправильный:

public Foo() {
    this.bar = new Bar();
}

Неправильный:

public Foo() {
    this.bar = ServiceLocator.Resolve<Bar>();
}

Неправильный:

public Foo(ServiceLocator locator) {
    this.bar = locator.Resolve<Bar>();
}

Правильно:

public Foo(Bar bar) {
    this.bar = bar;
}

Только последнее делает зависимость от Bar явной.

Что касается ведения журнала, есть правильный способ сделать это, не проникая в код вашего домена (этого не должно быть, но если это так, вы используете период внедрения зависимостей). Удивительно, но контейнеры IoC могут помочь в решении этой проблемы. Начните здесь.

Service Locator - это анти-шаблон, по причинам, превосходно описанным в http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx. Что касается ведения журнала, вы можете рассматривать это как зависимость, как и любую другую, и внедрить абстракцию через конструктор или инъекцию свойства.

Единственная разница с log4net заключается в том, что он требует типа вызывающего абонента, который использует службу. Использование Ninject (или какого-либо другого контейнера). Как узнать тип, запрашивающий услугу? описывает, как вы можете решить эту проблему (он использует Ninject, но применим к любому контейнеру IoC).

В качестве альтернативы вы можете рассматривать ведение журнала как сквозную проблему, которую нельзя смешивать с кодом бизнес-логики, и в этом случае вы можете использовать перехват, который предоставляется многими контейнерами IoC. http://msdn.microsoft.com/en-us/library/ff647107.aspx описывает использование перехвата с Unity.

Я считаю, что это зависит от обстоятельств. Иногда лучше одно, а иногда другое. Но я бы сказал, что в целом я предпочитаю DI. На то есть несколько причин.

1. Когда зависимость каким-то образом вводится в компонент, ее можно рассматривать как часть его интерфейса. Таким образом, пользователю компонента проще указать эти зависимости, потому что они видны. В случае внедренного SL или статического SL эти зависимости скрыты, и использование компонента немного сложнее.

2. Внедренные зависимости лучше подходят для модульного тестирования, потому что вы можете просто имитировать их. В случае SL вам нужно снова настроить зависимости Locator + mock. Так что работы больше.

Иногда ведение журнала можно реализовать с помощью AOP, чтобы оно не смешивалось с бизнес-логикой.

В противном случае варианты:

• используйте необязательную зависимость (например, свойство setter), а для модульного теста вы не вводите никакого регистратора. Контейнер IOC позаботится о его автоматической настройке, если вы запустите его в производственной среде.
• Когда у вас есть зависимость, которую использует почти каждый объект вашего приложения (наиболее распространенный пример - объект «logger»), это один из немногих случаев, когда одноэлементный анти-шаблон становится хорошей практикой. Некоторые люди называют эти «хорошие синглтоны» окружающим контекстом: http://aabs.wordpress.com/2007/12/31/the-ambient-context-design-pattern-in-net/

Конечно, этот контекст должен быть настраиваемым, чтобы вы могли использовать заглушку / макет для модульного тестирования. Еще одно предлагаемое использование AmbientContext - поместить туда текущего поставщика даты / времени, чтобы вы могли заглушить его во время модульного теста и при желании ускорить время.

Я использовал фреймворк Google Guice DI на Java и обнаружил, что он делает гораздо больше, чем просто упрощает тестирование. Например, мне нужен был отдельный журнал для каждого приложения (не класса) с дополнительным требованием, чтобы весь мой общий библиотечный код использовал регистратор в текущем контексте вызова. Это стало возможным благодаря внедрению регистратора. По общему признанию, весь код библиотеки нужно было изменить: логгер был внедрен в конструкторы. Сначала я сопротивлялся этому подходу из-за всех необходимых изменений кодирования; в конце концов я понял, что изменения имеют много преимуществ:

• Код стал проще
• Код стал намного надежнее
• Зависимости класса стали очевидными
• Если было много зависимостей, это было явным признаком того, что класс нуждается в рефакторинге.
• Статические синглтоны были устранены
• Исчезла необходимость в объектах сеанса или контекста
• Многопоточность стала намного проще, потому что контейнер DI мог быть сконструирован так, чтобы содержать только один поток, что исключало непреднамеренное перекрестное загрязнение.

Излишне говорить, что теперь я большой поклонник DI и использую его для всех, кроме самых простых приложений.

Мы пришли к компромиссу: используйте DI, но связывайте зависимости верхнего уровня в объект, избегая ада рефакторинга, если эти зависимости изменятся.

В приведенном ниже примере мы можем добавить ServiceDependencies без необходимости рефакторинга всех производных зависимостей.

Пример:

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.
}

Речь идет о «Локаторе услуг - это антипаттерн» Марка Симана. Я могу ошибаться здесь. Но я просто подумал, что тоже должен поделиться своими мыслями.

public class OrderProcessor : IOrderProcessor
{
    public void Process(Order order)
    {
        var validator = Locator.Resolve<IOrderValidator>();
        if (validator.Validate(order))
        {
            var shipper = Locator.Resolve<IOrderShipper>();
            shipper.Ship(order);
        }
    }
}

Метод Process () для OrderProcessor фактически не следует принципу «инверсии управления». Это также нарушает принцип единой ответственности на уровне метода. Почему метод должен заботиться о создании экземпляра

объекты (через новый или любой другой класс S.L.) он должен что-либо делать.

Вместо того, чтобы создавать объекты методом Process (), конструктор может фактически иметь параметры для соответствующих объектов (зависимости чтения), как показано ниже. Тогда КАК локатор услуг может отличаться от IOC?

контейнер. И это также поможет в модульном тестировании.

public class OrderProcessor : IOrderProcessor
{
    public OrderProcessor(IOrderValidator validator, IOrderShipper shipper)
    {
        this.validator = validator; 
        this.shipper = shipper;
    }

    public void Process(Order order)
    {

        if (this.validator.Validate(order))
        {
            shipper.Ship(order);
        }
    }
}


//Caller
public static void main() //this can be a unit test code too.
{
var validator = Locator.Resolve<IOrderValidator>(); // similar to a IOC container 
var shipper = Locator.Resolve<IOrderShipper>();

var orderProcessor = new OrderProcessor(validator, shipper);
orderProcessor.Process(order);

}

Я знаю, что этот вопрос немного устарел, я просто подумал, что внесу свой вклад.

На самом деле в 9 случаях из 10 вам действительно не нужен SL, и вам следует полагаться на DI. Однако в некоторых случаях вам следует использовать SL. Одна из областей, в которой я использую SL (или его разновидность), - это разработка игр.

Еще одно преимущество SL (на мой взгляд) - это возможность передавать internal классы.

Ниже приведен пример:

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();
    }
}

Как видите, пользователь библиотеки понятия не имеет, что этот метод был вызван, потому что мы не использовали DI, и в любом случае мы не сможем это сделать.

Если в примере используется только log4net как зависимость, вам нужно сделать только это:

ILog log = LogManager.GetLogger(typeof(Foo));

Нет смысла вводить зависимость, поскольку log4net обеспечивает детальное ведение журнала, принимая тип (или строку) в качестве параметра.

Кроме того, DI не коррелирует с SL. IMHO цель ServiceLocator - разрешить необязательные зависимости.

Например: если SL предоставляет интерфейс ILog, я напишу daa регистрации.

Я знаю, что люди действительно говорят, что DI - это единственный хороший шаблон IOC, но я этого не понимаю. Постараюсь немного продать SL. Я буду использовать новую структуру MVC Core, чтобы показать вам, что я имею в виду. Первые двигатели DI действительно сложны. Что люди на самом деле имеют в виду, когда говорят, что DI, так это использование какой-то структуры, такой как Unity, Ninject, Autofac ... которые делают всю тяжелую работу за вас, где SL может быть таким же простым, как создание фабричного класса. Для небольшого быстрого проекта это простой способ выполнить IOC, не изучая всю структуру для правильного DI, они могут быть не такими сложными в освоении, но все же. Теперь о проблеме, которой может стать DI. Я буду использовать цитату из документации MVC Core. «ASP.NET Core изначально разработан для поддержки и использования внедрения зависимостей». Большинство людей говорят, что о DI «99% вашей кодовой базы не должны знать вашего контейнера IoC». Так зачем им разрабатывать с нуля, если только 1% кода должен знать об этом, разве старый MVC не поддерживает DI? Ну, это большая проблема DI, это зависит от DI. Чтобы заставить все работать «КАК ЭТО ДОЛЖНО БЫТЬ СДЕЛАНО», требуется много работы. Если вы посмотрите на новую инъекцию действия, это не зависит от DI, если вы используете атрибут [FromServices]. Теперь DI люди скажут НЕТ, вы должны использовать Factories, а не это, но, как вы можете видеть, даже люди, делающие MVC, не сделали это правильно. Проблема DI видна в фильтрах, также посмотрите, что вам нужно сделать, чтобы получить DI в фильтре.

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.");
        }
    }
}

Если бы вы использовали SL, вы могли бы сделать это с помощью var _logger = Locator.Get () ;. А затем мы подошли к просмотрам. При всей доброй воле в отношении DI им пришлось использовать SL для просмотров. новый синтаксис @inject StatisticsService StatsService такой же, как var StatsService = Locator.Get<StatisticsService>();. Самая разрекламированная часть DI - это модульное тестирование. Но то, что делают люди и выше, - это просто бесполезно тестируют там имитирующие сервисы или им приходится подключать к нему DI-движок, чтобы проводить настоящие тесты. И я знаю, что вы можете сделать что угодно плохо, но люди в конечном итоге создают локатор SL, даже если они не знают, что это такое. Где не так много людей делают DI, даже не прочитав сначала. Моя самая большая проблема с DI заключается в том, что пользователь класса должен знать о внутренней работе класса в других, чтобы использовать его.
SL можно использовать хорошо, и он имеет некоторые преимущества, прежде всего его простота.

Для DI вам нужна жесткая ссылка на сборку внедренного типа? Я не вижу, чтобы кто-нибудь об этом говорил. Для SL я могу указать своему преобразователю, где динамически загружать мой тип, когда это необходимо, из config.json или аналогичного. Кроме того, если ваша сборка содержит несколько тысяч типов и их наследование, нужны ли вам тысячи каскадных вызовов поставщику службы для их регистрации? Вот о чем я действительно вижу много разговоров. Большинство из них говорят о преимуществах DI и о том, что это такое в целом, когда дело доходит до того, как реализовать его в .net, они представили метод расширения для добавления ссылки на сборку жестко связанных типов. Для меня это не очень разобщает.