Есть ли разница между ними, а не задавать и получать объекты в массиве по ключу?Шаблон реестра Vs Диалог локатора обслуживания Vs Container Injection для зависимостей
class Registry
{
private $container=array();
public static function Set($name,$object){
self::$container[$name]=$object;
}
public static function &Get($name){
return self::$container[$name];
}
}
Registry pattern это шаблон используется для поиска объекта, зная только его имя. Этот шаблон хранит экземпляры объектов внутри и использует сопоставление словаря для извлечения этих экземпляров позже.
ди контейнер содержит реестр, который имеет отображение типов объектов к абстракций. Он более продвинут в том смысле, что когда объект разрешен, он создается, и все остальные объекты зависят от.
При запросе объекта из DI контейнера, вы получите граф объектов начиная с объектом вы запрашиваете как корень. Каждый зависимый объект вводится автоматически путем рекурсивного прохождения через конструктор каждого класса, начиная с классов, не имеющих зависимостей, и создания экземпляра каждого объекта с использованием реестра в качестве руководства.
Зависимость от инъекции - это номер , который doesn't necessarily use a DI container. Шаблон DI состоит из composition root, который находится у входной точки приложения. Корень композиции - это место, где регистрируются типы и где создается экземпляр объекта-объекта . Когда экземпляр корневого объекта создается, приложение запускается самостоятельно. Само приложение не имеет ссылки на контейнер DI и не тесно связано с ним.
служба локатор, по мнению многих людей, чтобы быть anti-pattern. Идея заключается в том, что вы либо вводите контейнер в свой объект, либо используете статическую ссылку на контейнер DI для создания экземпляров во время выполнения.
Основное отличие заключается в том, что приложение явным образом зависит от (таким образом плотно соединена с) контейнера DI.
Другим недостатком использования Service Locator является то, что, поскольку вы вводите контейнер DI, из конструкторов классов не видно, с какими интерфейсами он зависит. Вместо этого вам необходимо проконсультироваться с документацией или проанализировать исходный код, чтобы определить, что такое зависимости класса.
Несмотря на то, что считается анти-шаблоном, есть еще некоторые ситуации, когда это имеет смысл использовать. Однако его следует рассматривать как последнее средство после исчерпания всех других вариантов (окружающий контекст, инъекция свойств и т. Д.).