ZF2 устарел: ServiceManagerAwareInterface

Question

ZF2 устарел: ServiceManagerAwareInterface

Сегодня я обновил свой проект, и я получил это предупреждение:

Устаревший: ServiceManagerAwareInterface устарел и будет
удалено в версии 3.0 вместе с ServiceManagerAwareInitializer.
Пожалуйста, обновите ваш класс X, чтобы удалить реализацию, и начните
вместо этого вводя ваши зависимости через фабрику

У меня есть некоторые основные Base классы, которые реализуют ServiceManagerAwareInterface и несколько классов, расширяющих эти базовые классы.

Так стоит ли создавать дополнительные фабричные классы для каждого из этих классов? или лучше использовать 1 АбстрактЗавод для каждого модуля и инициировать классы там?

Доза, использующая эффективность воздействия AbstractFactory?

Какова лучшая практика для внедрения одной (или 2) общей зависимости во многие классы?

ОБНОВИТЬ :
Даже несмотря на то, что я принял ответ @ AlexP, но у меня есть некоторые опасения по поводу предоставления конструктора броска зависимостей. Представьте себе такой сценарий: у меня есть контроллер с парой действий, чтобы, например, ActionA требовался ServiceZ, а ActionB требовался ServiceY и ServiceX, а ServiceX также зависел от ServiceM и ServiceN. Теперь каждый раз, когда я вызываю ActionA, мой контроллер запускается со всеми этими службами, но ActionA требуется только 1 служба, где мой контроллер загружен 5 службами. Это хорошая практика? это правильный путь? не будет ли это иметь плохую производительность, так как при каждом запросе запускаются сервисы, которые мы вообще не будем использовать во время этого запроса?

Прямо сейчас я позволяю каждому сервису / контроллеру заботиться о своих потребностях и загружать сервисы когда это нужно им.

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

Цените любой вклад в это.

6

dependency-injection php zend-framework2 zend-framework3

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Фабрика на обслуживание обычно является идеальной целью; однако есть много случаев, когда у вас есть похожие классы, которые имеют схожие зависимости, и создание такого количества фабрик для каждого из них будет ненужным и сложным в обслуживании.

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

Это вводит некоторые проблемы.

Звонки в $serviceManager->get() или же $serviceManager->has() потребуется абстрактная фабрика, чтобы проверить, может ли она создать службу, используя ее canCreateServiceWithName() Способ; с несколькими абстрактными фабриками это может привести к значительному снижению производительности.
Абстрактная фабрика не имеет понятия «псевдоним» службы; функциональность, предлагаемая менеджером сервиса. Реализация требует, чтобы вы соответствовали $requestedName службы. Это проблема, если у вас есть вызовы для служб, использующие как полное имя службы, так и псевдоним.
Абстрактные фабрики тесно связаны с каркасом ZF2.

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

Обратите внимание, что фабрика теперь принимает дополнительный обязательный аргумент, $requestedName; v2 уже передал этот аргумент, но он не был указан в самом интерфейсе.
Поскольку фабрики теперь могут ожидать получения имени службы, они могут повторно использоваться для нескольких служб, в основном замена абстрактных фабрик в версии 3.

Таким образом, мы уже можем использовать стандартные фабрики множественный время для аналогичных услуг (в ZF2).

Очень простой пример того, как создать подобный сервис с одной фабрикой.

'service_manager' => [
'factories' => [
'My\Service\Foo' => 'My\Factory\SharedFactory',
'My\Service\Bar' => 'My\Factory\SharedFactory',
'My\Service\Baz' => 'My\Factory\SharedFactory',
],
],

namespace My\Factory;

class SharedFactory
{
public function __invoke($serviceLocator, $name, $requestedName)
{
if (! class_exists($requestedName)) {
throw new ServiceNotCreatedException("$requestedName could not be found!");
}

return new $requestedName(
$serviceLocator->get('SomeDependacy1'),
$serviceLocator->get('SomeDependacy2')
);
}
}

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

4