Как вызвать метод в Symfony с autowire'ингом?

Question

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

Доброго времени суток уважаемые!

Собственно вопрос уже обозначен в заголовке. Как вызвать метод сквозь контейнер?

<?php
class Some
{
    public function any(DependencyA $a, DependencyB $b)
    {
        // do something
    }
}

// Вызов
// service.name должен быть зарегистрированным в services.yml
$instance = $container->get('service.name'); 

// А дальше?

Аналогичный пример в Laravel 5+:

<?php
class Some
{
    public function any(DependencyA $a, DependencyB $b, $some)
    {
        // do something
    }
}

// Вызов
// Получение инстанса из контейнера (аналогично вызову $container->get('service.name') в симфони )
$instance = $container->make(Some::class);

// Все аргументы из контейнера 
// т.е. $a и $b, срабатывает автоматический автовайринг для неуказанных аргументов
// кроме $some - он указывается явно во время вызова
$container->call([$instance, 'any'], [ 'some' => 42 ]);

Answer 1

[Radik_Wind]

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

Comments

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

Спасибо, я в курсе, вы вопрос хотя бы прочитали? =)

[Radik_Wind]

Кирилл Несмеянов: Вопрос прочитал, именно поэтому и написал. Из за того, что вы хотите зависимости передавать в метод сервиса, я вам и дал вам такой ответ, т.к. такой подход приведет к невозможности в будущем в случае необходимости переопределить поведение без глобального переопределения сервисов которые могут быть использованы в качестве зависимостей в других компонентах системы.

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

Radik_Wind: Почему это? Метод N требует интерфейс A и B - классический принип инверсии контроля, осталось их как-либо автоматом посылать туда. Хорошо бы чтобы этим занимался сам DI контейнер, т.к. это его задача предоставлять зависимости, но в реализации симфони он этого тупо не умеет и является скорее сервис локатором, а не DI.

[Radik_Wind]

Кирилл Несмеянов: Во время выполнения вы не должны передавать зависимости, данные вопросы решаются на этапе создания/инициализации сервиса, но ни как не во время выполнения. В случае, если у вас возникает необходимость передавать зависимости во время выполнения, то вам явно следует пересмотреть дизайн вашего сервиса.

[cold147]

Radik_Wind: Почему нет? Вы же пишите так правда?:
```
function someAction(Request $request)
{
}
``

Так почему бы не резолвит нужных сервисов в таких случаях?
(Заметьте ТОЛЬКО в таких случаях)

это избавит нас от тонны однотипных действий

[Radik_Wind]

cold147: Да все верно, так делают, но это не имеет ни какого отношения к DI, стоит четко понимать грань между зависимостями и аргументами методов, так же стоить знать, что весь этот сахар весьма негативно сказывается на производительности. В случае, если вы хотите делать аналогичным образом, то вы должны реализовать свой ArgumentResolver который будет позволять вам резолвить аргументы так как вы захотите, тот что есть для контроллеров ControllerResolver вам не подойдет.

[cold147]

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

но это не имеет ни какого отношения к DI

Я ничего про DI не говорил.

Мой посыл был о том что к дизайну проекта это не повредит, если использовать к месту.

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

Radik_Wind: почему это не имеет отношения к DI? DI == Dependency Injecton, т.е. автоматичекая подстановка (инъекция) зависимостей, оно делится на три типа - инъекции в конструктор, инъекции в поля и инъекции в методы. В Symfony присутсвует два из них, насколько я понял - это в конструктор и в поля (сквозь вызов метода set). И в костыльном виде инъекции в методы контроллера. При этом в современной практике инъекции в поля являются антипаттерном, в тоже время инъекции в конструктор и в методы - общепринятые "нормальные" подходы.

[Radik_Wind]

Кирилл Несмеянов: В методы сервиса передаются параметры необходимы для работы, а не зависимости. В классическом понимании паттерна существует 3 способа внедрения зависимостей:
- Конструктор
- Свойства
- Методы
Все эти три способа присутствуют в DI Symfony2, поэтому и не имеет отношения к DI.

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

Radik_Wind: а почему тогда это называется DI, а не Parameters Injection? ;)

Так вот, если говорите что всё же есть инъекции в методы, то как это вызвать так же, как в phpdi, laravel, джавовских реализациях и проч.? Метод в моем случае должен соответствовать поведению метода контроллера, т.к. это и есть почти что контроллер, но взаимодействующий с другим источником данных, нежели хттп запрос.

[Radik_Wind]

Кирилл Несмеянов: Уважаемый, я устал уже объяснять в чем вся загвоздка DI и почему вы понимаете под ним нечто иное, передача аргументов в сервис не задача DI контейнера, его основная задача внедрение зависимостей от других компонентов/сервисов системы, вам лучше всего стоит ознакомиться с литературой (возможно, я что то не так объясняю), хорошая статья про DI, есть тут www.martinfowler.com/articles/injection.html от не безызвестного автора М. Фаулера, прочтите разъяснения автора который стоял у истоков, лучше него, я вряд ли смогу вам объяснить.

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

Radik_Wind: Хорошо, спасибо большое =)

Answer 2

[voronkovich]

В Symfony-контейнере случай описанный для Laravel работать не будет.
Сделайте без autowiring. Или добавьте для зависимостей сеттеры, тогда контейнер внедрит их автоматически:

<?php
class Some
{
    public function setDependencyA(DependencyA $a)
    {
        $this->dependencyA = $a;
    }

    public function any()
    {
         $this->dependencyA->someMethod();
          // do something 
    }
}

Comments

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

Вполне годный вариант. НО! Оно срабатывает один раз, с тем же успехом можно инжектить в конструктор и не париться.

Но проблема в том, что требуется, чтобы при каждом вызове метода - прилетал новый инстанс зависимоси. Пример с контроллером:

use Symfony\Component\HttpFoundation\Request;

class SomeController
{
    public function index(Request $request) 
    {
        // При каждом вызове метода index - возвращается новый реквест, в зависимости от, собственно, реквеста
    }
}

[voronkovich]

Кирилл Несмеянов:
В таком случае вам может помочь shared=false

См. symfony.com/doc/current/cookbook/service_container...

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

voronkovich: вы меня ну вообще не поняли. Метод, допустим A вызывается 10 раз и вы хотите сказать, то при каждом вызове метода A декларированный в нём $this->someDependency будет каждый раз новым? Нет, нифига - он будет тем же самым, что установили один раз в конструкторе этого объекта или через сеттер.

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

voronkovich: В случае же вызова этого метода A с какими-либо аргументами - вы сами вольны передавать ему какие угодно аргументы, проблема лишь в том, чтобы
1) определить что это за аргументы
2) есть ли они в контейнере
3) подставить их из контейнера (если есть)

[voronkovich]

Используя shared=false вы можете сделать следующее (без autowiring):

$a = $container->get('dependency_a');
$b = $container->get('dependency_b');
$instance->any($a, $b, ...);

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

voronkovich: Аргументы метода могут быть вариативными, мы не можем знать заранее что именно он требует. Автовайринг это решает.

[voronkovich]

Тогда вам придется сделать расширение или сервис который при помощи рефлексии и api контейнера сделает все как в Laravel. Из коробки в симфони этого нет.

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

voronkovich: Подобные возможности и в php-di, и в laravel и в прочих. А в симфони нет - это я и боялся услышать =(

[cold147]

voronkovich: не получится через апи контейнера, в рантайме он почти ничего не умеет

[cold147]

Кирилл Несмеянов: можно использовать php-di в симфони

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

cold147: ну это да, только тащить целый компонент ради одной подобной плюшки - как-то не хочется. Думаю просто стоит отказать от подобного.

[voronkovich]

cold147: Вы правы, посмотрел апи контейнера - там ничего полезного нет.
Кирилл Несмеянов: По видимому, вам придется на самом деле отказаться от этой фичи.