Контейнер IOC & доступ к реализации из контейнера

Фон

Как упоминалось в этой статье ,

  

Инверсия управления может быть достигнута с помощью различных механизмов, таких как: Шаблон разработки стратегии , Шаблон локализации службы (SLP) , Заводская модель и Инъекция зависимостей (DI) .

Отсутствует ясность в вышеприведенном заявлении, потому что ниже мое понимание.

1) Создание контейнера

Создание контейнера зависимостей или контейнер IOC не требует любого из этих шаблонов проектирования (см. выше). Нам нужны эти шаблоны проектирования, чтобы получить доступ к реализации из этого контейнера (который уже создан). Вот код C , где init_handlers() создать контейнер (imagehandlers в config.c ) реализаций, настроенных в config.txt

2) Доступ к контейнеру из контейнера

Чтобы получить доступ к реализации из контейнера, например,

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

или

Полагайтесь на механизм местоположения службы, который реализуется с помощью шаблона локатора службы . Вот код C , где displayMenu() находит службу из контейнера imagehandlers, на основе заданного ввода (scanf("%s",filename);)


Итак, Инъекция зависимостей или Шаблон локатора службы имеет ничего не делать с созданием контейнера IOC , но для доступа к реализации из этого контейнера.

Например, в Spring ,

ApplicationContext appContext = new ClassPathXmlApplicationContext("Springbeans.xml")

создайте контейнер IOC с одноточечными экземплярами всех компонентов, сконфигурированных в Springbeans.xml, предполагая, что компоненты не имеют прототип и

MessageBean mBean = (MessageBean)appContext.getBean("messagebean"); 

находит службу messageBean, используя шаблон локатора службы из appContext.

1) Для этой строки кода ApplicationContext appContext = new ClassPathXmlApplicationContext("Springbeans.xml"), который создает контейнер зависимостей, правильно ли сказать, что при создании контейнера ничего нет (например, DI или SLP)?

2) Почему appContext не называется контейнером ? Вместо этого, почему appContext называется контейнер IOC ?

3 голоса | спросил user1787812 6 Jpm1000000pmSat, 06 Jan 2018 13:55:44 +030018 2018, 13:55:44

3 ответа


1

Единство, например, - это , называемое контейнером для инъекций зависимостей

https://msdn.microsoft.com/en-us/library /ff647202.aspx

Microsoft вернет это снова, поэтому вы никогда не должны использовать java.

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

Скажем, что у меня есть класс, настроенный на установку

class myClass
{
    myClass(IService s)
}

Я могу и, вероятно, в большинстве случаев просто создать экземпляр «вручную» в коде

main(string[] args)
{
    var m = new myClass(service);
}

Однако. Если im работает в какой-то структуре, часто я не буду кодировать структуру низкого уровня приложения. Just Views, ViewModels, Controllers, Behaviors или некоторые другие типы объектов, которые сама инфраструктура будет создавать при необходимости.

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

Вместо того, чтобы вручную обрабатывать фабрику для каждого класса, я могу использовать отражение для создания универсальной фабрики, которая может создавать любой класс. Это объект IoC или DI Container.

ответил Ewan 6 Jpm1000000pmSat, 06 Jan 2018 15:36:41 +030018 2018, 15:36:41
1

A Консоль IoC /DI - это среда для управления зависимостями приложения. Поскольку это структура, она должна определять способ создания и загрузки /впрыскивания определенных зависимостей, когда и где это необходимо. Итак, часть

  

1) Создание контейнера

     

Создание контейнера зависимостей или контейнера МОК не требует   эти шаблоны проектирования (упомянутые выше) ...

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

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

Для дальнейшего чтения и лучшего понимания я предлагаю вам взглянуть на приведенные ниже ссылки:

  1. Разница между «инверсией управления», «инверсией зависимостей» "И" Развязка "
  2. Что такое контейнер IoC или контейнер DI
  3. Понимание инверсии Управление, инжекция зависимостей и локатор обслуживания
ответил ichantz 6 Jpm1000000pmSat, 06 Jan 2018 17:35:26 +030018 2018, 17:35:26
1
  

1) Для этой строки кода ApplicationContext appContext = new ClassPathXmlApplicationContext ("Springbeans.xml"), который создает контейнер зависимостей, правильно ли сказать, что создание контейнера не имеет ничего общего с шаблоном проектирования (например, DI или SLP )?

Эта вещь является локатором службы. Но анти-шаблон с сервисными локаторами должен распространять их. Храните это только в корне вашего состава (обычно в главном), и это нормально.

  

2) Почему appContext не называется контейнером зависимостей? Вместо этого, почему appContext называется контейнером IOC?

IOC зависит от полиморфизма. Это требует не знать, с чем вы разговариваете. Это делается здесь, заставляя вас максимально разделить код конструкции от кода поведения. Построить строительство на другом языке (обычно xml). Это разделение позволяет использовать код, чтобы точно знать, с чем он разговаривает.

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

ответил candied_orange 6 Jpm1000000pmSat, 06 Jan 2018 21:30:32 +030018 2018, 21:30:32

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132