Теория: «Сервисный локатор» «Контейнер IOC» «IOC» «DI»

Question

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

1) «DI» и «IOC» - то же самое.

2) «МОК Контейнер» - это экземпляр объекта, который может разрешить зависимости, как:

void Test() 
{ 
    // create IOC Container to resolve 
    // dependences for SomeMethod method 
    var container = new SomeContainer(); 
    container.For(typeof(IEmaleSender), typeof(SuperEmaleSender)); 

    // Pass IOC Container to resolve dependences in SomeMethod 
    SomeMethod(container); 
} 

void SomeMethod(SomeContainer container) 
{ 
    IEmaleSender emailSender = container.Resolve(IEmaleSender); 
    emailSender.SendEmail(); 
} 

3) «Service Locator» - это что-то вроде статический объект, который содержит Dictionary<Type, object> где значение экземпляр типа ключа. И этот статический объект имеет 2 метода: Add и Get. Так что я могу добавить объект на старте моего приложения и запросить его везде:

void Test() 
{ 
    // Assign instanse of SuperEmaleSender to Locator 
    SuperEmaleSender emailSender = new SuperEmaleSender() 
    SomeLocator.Add(typeof(SuperEmaleSender), emailSender); 

    SomeMethod(); 
} 

void SomeMethod() 
{ 
    SuperEmaleSender emailSender = SomeLocator.Get(typeof(SuperEmaleSender)); 
    emailSender.SendEmail(); 
} 

4) Это хорошая практика, чтобы объединить «Service Locator» и «Container МОК». Таким образом, вы можете создать экземпляр «контейнера IOC» при запуске приложения и запросить его через «Service Locator» со всего мира.

5) В ASP MVC5 уже включен «Сервисный локатор». Я говорю о DependencyResolver.

Благодарим за помощь.

Answer 1

Service Locator - ПОЧТИ чрезвычайно примитивная инъекция зависимостей. Обычно он позволяет вам возвращать экземпляры singleton. На самом деле это не DI, потому что вам нужно вручную получать экземпляры вручную и новые объекты, а затем позволить движку DI сделать это за вас (новый объект вверх и вставить ссылки на службы в них). DI также дает вам больший контроль над временем жизни объектов.

Answer 2

Что касается объединения локатора сервисов с IoC - если у вас есть подходящий контейнер IoC, вы действительно не должны использовать сервисный локатор (или, возможно, в большинстве случаев его не следует использовать), потому что вся точка IoC и DI должен передавать зависимости извне класса и явно указывать на зависимости от этого класса. Использование локатора сервисов скрывает зависимость. Service locator is by some people considered an anti-pattern.

Answer 3

DI обозначает впрыск Depency и IoC для инверсии управления. Представьте, что у вас есть класс, который обращается к базе данных. Ответственность этого класса заключается в том, чтобы вставить элемент, но для этого требуется подключение к базе данных. Если ответственность класса заключается только в том, чтобы вставить элемент, он не будет знать, как начать это соединение, только как его использовать. Думая об этом, вы будете устанавливать соединение как зависимость этого класса, передавая ответственность за создание этого соединения любому, кто хочет его использовать. Вы инвертируете элемент управления, используя инъекцию зависимостей, передавая ответственность любому, кто знает, как работает соединение.

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

Вы можете увидеть этот вопрос для более детального ответа: Inversion of Control vs Dependency Injection