Можно ли в symfony динамически внедрять зависимости?

Question

[galliard]

Предположим, у нас есть сервис Foo, и он принимает в конструктор BarInterface. И есть 3 сервиса, реализующие этот интерфейс, условно назовем их Bar1, Bar2 и Bar3. Так вот, в зависимости от каких-либо условий (например параметров http-запроса пользователя) нужно внедрить в Foo экземпляр Bar1, Bar2 или Bar3.

Можно ли где-то описать логику выбора сервиса для внедрения?

Answer 1

[Кирилл Несмеянов]

По-умолчанию симфонёвый контейнер это не позволяет. Есть 3 варианта развития:
1) Не сопротивляться и не использовать в этом случае контейнер, а использовать, например, фектори (т.е. чтобы контейнер возвращал этот самый фектори, который в зависимости от чего-либо возвращал нужный сервис).
2) Если Symfony 3.x и нужен сервис в контроллерах, то можно использовать Param Resolver: https://symfony.com/doc/current/controller/argumen...
3) Можно написать свой бридж на более мощный контейнер, например Laravel, в этом случае надо в обязательном порядке наследоваться от симфонёвого (чёртова симфонёвая кодогенерация) и зарегистрировать его внутри AppKernel (там есть метод получения класса контейнера).

P.S. А ещё в последних симфонях добавили Service Locator механизм (слайс контейнера), в теории можно придумать что-нибудь с ним.

Comments

[Алексей Скобкин]

Ну в целом собирать объекты по-разному в зависимости от входных данных - это как раз про фабрику.

[Кирилл Несмеянов]

Алексей Скобкин, ну не всегда. В той же ларке часть архитектуры построена на ленивых "динамических" зависимостях. Пример: Есть, грубо говоря, секьюрити, после его прохождения в контейнере появляется Authenticated интерфейс (аналог симфонёвого UserInteface, только более абстрактный), который можно использовать для автовайринга и прочего. В случае симфони огромных проблем и боли доставляет вытаскивание оного из токен стораджа или других мест.

Есть и другие примеры, в ларке, фактически обычный контроллер работает так же через контейнер (т.е. Request сам связывается с экшеном), а не через специальные костыли (HttpKernel), как в симфони. Это и минус, т.к. требует строгого упорядочивания логики внедрения, но всё же архитектура предоставляет удобные и надёжные механизмы для этого (миддлвари, например, или события контейнера).

Так что фабрика - это лишь частное решение, вызванное ограниченностью симфонёвого контейнера.

[galliard]

2) Если Symfony 3.x и нужен сервис в контроллерах, то можно использовать Param Resolver:

Да, я что-то совсем забыл про него. Это решит часть проблем, но все же хотелось бы более универсального решения.

3) Можно написать свой бридж на более мощный контейнер, например Laravel, в этом случае надо в обязательном порядке наследоваться от симфонёвого (чёртова симфонёвая кодогенерация) и зарегистрировать его внутри AppKernel (там есть метод получения класса контейнера).

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

Answer 2

[Artem Moseev]

https://symfony.com/blog/new-in-symfony-3-4-local-...
Local binding

Comments

[galliard]

Здесь нет динамики. Это просто конфигурирование разных сервисов с разными зависимостями.

[Artem Moseev]

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

Answer 3

[Виктор Дидицкий]

Решить проблему в лоб, к сожалению, не получится.
Вам нужен промежуточный слой между сервис контейнером и вашим сервисом. В симфони есть механизм для подобных задач: symfony.com/doc/current/service_container/compiler...

Работает это так:

1. Вы декларируете сервисы Bar1, Bar2, Bar3 указывая им определенный тег:

services:
   bundle.service.bar1:
      class: .../Bar1
      arguments:
         ...
      tags:
         - { name: bar }

2. Создаете сервис, например BarProvider, который будет содержать ссылки на сервисы Bar1, Bar2, ... и предоставляющий метод(ы) для их получения.

3. Создаете Compiler, которые достает из сервис-контейнера все сервисы, имеющие тег bar и складывает их в BarProvider (BarProvider должен иметь метод для добавления BarInterface)

4. Инжектите BarProvider в нужный вам сервис и достаете из него требуемый сервис Bar