Локатор сервисов, Инъекция зависимостей (и контейнера) и инверсия управления

Я думаю, вы правильно поняли Service Locator.

Об зависимостях Injection означает, что если у объекта есть зависимости конструктора и / или свойства, они вводятся в объект снаружи, в отличие от объекта, получающего сами зависимости

 public class MyClass { private $_dep; public function __construct($dep=null) { //$dep has to be injected $this->_dep=$dep; } //this is wrong because it couples MyClass to a specific Dependency implementation public function __construct() { $this->_dep=new Dependency(); } } $dep=new Dependency(); $obj=new MyClass($dep); 

Обычно конструктор принимает абстракцию (интерфейс) в качестве параметра, а вне класса создается конкретная реализация, которая затем передается конструктору при создании нового экземпляра MyClass.

Контейнер DI автоматически обрабатывает инъекцию зависимостей. Вы просто настраиваете его, чтобы он знал, какие конкретные классы должны быть возвращены при запросе абстракции. Контейнер обрабатывает создание объекта, впрыскивает зависимости через конструктор и / или свойства. В зависимости от контейнера (я не знаю примера для php, я знаком только с .Net контейнерами DI), возможно, вам придется регистрировать также типы объектов, которые могут быть созданы им.

Инверсия управления означает, что вместо класса более высокого уровня, зависящего от реализации класса (зависимости) более низкого уровня, управление инвертируется, поэтому реализация класса более низкого уровня зависит от абстракции, требуемой классом более высокого уровня.

 //abstraction defined for the use of higher level class public interface IRepository {} // that's the dependency, the lower level class public class XmlRepository implements IRepository {} //the higher level class public class MyClass { public function __construct(IRepository $repo) {} } 

IoC и DiC идут вместе, поскольку контейнер DI предлагает функцию IoC.

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

Когда вы сравниваете регистр и разрешаете части контейнера IoC с помощью Locator, это похоже на то же самое.

Контейнер IoC можно использовать как локатор сервисов, который считается анти-шаблоном. Когда вы используете Service Location, вам всегда нужно активно вызывать сервис-локатор по всей вашей архитектуре. Таким образом, вы отключаете свои классы, но, с другой стороны, вы связываете их всех с Service Locator. Кроме того, обнаружение зависимостей сложнее с помощью Locator службы, поскольку вы скрываете зависимости. В то время как с Injection Dependency вы делаете зависимости «общедоступными» с помощью Injection Constructor.

Когда вы используете контейнер IoC, вы используете инъекцию зависимостей (инжекция конструктора или впрыск объектов). Контейнер IoC теперь может преобразовывать граф зависимостей, просматривая параметры конструктора и создавая весь граф зависимостей. Это называется автоматической проводкой . Локатор службы не может устанавливать зависимости от автоматической проводки. Как я уже упоминал, вы не вынуждены использовать автоматическую проводку, вы можете легко использовать контейнер IoC, как локатор сервисов, просто позвонив контейнеру IoC в каждый класс напрямую, НО ВЫ НЕ ДОЛЖНЫ !

См. Также: https://stackoverflow.com/a/11319026/175399