проверяя я понимаю разницу между IoC, Ioc Container, DI и сервисным локатором - PullRequest
Новая
       38

проверяя я понимаю разницу между IoC, Ioc Container, DI и сервисным локатором

6 голосов
/ 11 сентября 2011

читайте много постов о разнице между 3 идиомами. Но запутался, потом наткнулся на эту статью: http://martinfowler.com/articles/injection.html

просто хочу посмотреть, правильно ли я понял. Пожалуйста, поправьте меня, если я ошибаюсь. Пожалуйста, сообщите мне исправления и дополнения:

IoC - это концепция отделения приложения от реализации службы, которую он использует. Приложение содержит ссылку на Iservice и не отвечает за конкретную службу.

Существует как минимум два способа добиться этого:

  1. DI - конкретный сервис вводится в виде параметра ctor / throw в интерфейсный метод / throw (инъекция интерфейса броска ( что означает последнее? )

  2. ServiceLocator - это компонент, который знает все конкретные службы, которые могут понадобиться приложению. Приложение явно запрашивает конкретную услугу от локатора.

* Контейнер IoC на самом деле является фабрикой элементов управления («провайдер»).

Меня немного смутила часть "когда предпочесть (1) или (2)" в статье. Может ли кто-нибудь сказать, исходя из собственного опыта, словами непрофессионала?

«У сервисного локатора есть небольшое преимущество из-за его более простого поведения. Однако, если вы создаете классы для использования в нескольких приложениях, то Dependency Injection является лучшим выбором.» -> Как локатор более прост? потому что он использует вызов метода явно? Что лучше использовать DI, когда есть несколько приложений?

1 Ответ

4 голосов
/ 11 сентября 2011

IoC - это концепция отделения приложения от реализации службы, которую он использует.

Это правда, что IoC идет рука об руку с развязкой интерфейсов от реализаций, но я вижу,это как более общий принцип. Этот ответ SO дает очень хорошее объяснение концепции.

Существует как минимум два способа добиться этого:
1) DI
2) ServiceLocator

Я бы не сказал, что шаблон Service Locator является примером инверсии управления.Скорее наоборот - когда вы используете сервисный локатор, вы активно приобретаете требуемые зависимости, никто больше не делает это за вас (в отличие от DI, где контейнер обрабатывает зависимости для вас, вы просто должны дать емувозможность сделать это - установщик, параметр конструктора или путем реализации метода интерфейса ввода).

Как локатор более прост?потому что он использует вызов метода явно?

Я думаю, что Мартин Фаулер ссылается на общую идею IoC, которая может усложнить понимание кода, если вы никогда не видели концепцию IoC / DI, использованную ранее,С другой стороны, код, использующий Service Locator для получения некоторых зависимостей, может быть легче понять при первом обращении.

Что лучше использовать DI при наличии нескольких приложений?

Когда вы создаете компонент, который предполагается использовать повторно, преимущество DI состоит в том, что он не делает ваш компонент зависимым ни от чего, кроме исходной зависимости (в примере MF, MovieLister зависит только от MovieFinderинтерфейс при использовании DI).Кроме того, другим пользователям довольно просто использовать ваш компонент - нужно просто передать зависимости, используя предоставленные вами средства DI.

При использовании локатора службы вы также добавляете зависимость от интерфейса службыСам локатор.С отдельным интерфейсом для локатора это может не быть проблемой.Но пользователям вашего компонента также может быть труднее удовлетворить зависимости вашего компонента, как пишет MF:

Разница возникает, если список - это компонент, который я предоставляю приложению, котороедругие люди пишут.В этом случае я мало что знаю об API локаторов сервисов, которые собираются использовать мои клиенты.У каждого клиента могут быть свои несовместимые сервисные локаторы.

...