Понимание конфигурации и контейнера службы Symfony Bundle

Как насчет зависимостей !?

Хорошо, если вы обратили внимание, вы, возможно, заметили, что наш пример на самом деле не вводил никаких зависимостей, только простой параметр. Это правда, я хотел сохранить первый пример как можно более простым. А что если нам нужно сделать многоязычное приложение? Нам нужно будет использовать какую-то систему перевода, и сервису Greeter она понадобится для перевода приветствия.

Во-первых, давайте изменим класс обслуживания следующим образом:

 namespace   Cvuorinen \ExampleBundle\Service ; 

 use   Symfony \Component\Translation\TranslatorInterface ; 

 class   Greeter 
 { 
     public   function  __construct ( $greeting ,   TranslatorInterface  $translator ) 
     { $this -> greeting =  $greeting ; $this -> translator =  $translator ; 
     } 

     public   function  greet ( $name ) 
     { 
         return  $this -> translator -> trans ( $this -> greeting )   .   ' '   .  $name ; 
     } 
 } 

Тогда давайте изменим конфигурацию, чтобы внедрить службу переводчика следующим образом:

 parameters : cvuorinen_example . greeter . class :   Cvuorinen \ExampleBundle\Service\Greeter cvuorinen_example . greeter . greeting :   "Hello" services : cvuorinen_example . greeter : 
         class :   % cvuorinen_example . greeter . class % arguments : 
             -   % cvuorinen_example . greeter . greeting % 
             -   @translator 

В остальном это точно так же, как и в предыдущем примере, единственное отличие — в разделе arguments конфигурации службы greeter. Здесь мы добавили еще один аргумент конструктора, на этот раз это другой сервис. На сервисы можно ссылаться в конфигурации, добавив к ним префикс @ -character. Мы используем сервис Symfony Translator по умолчанию, который называется «переводчик». Некоторые базовые службы не имеют пространства имен в своих @cvuorinen_example.translator , но вы также можете добавить собственную службу переводчиков, например, с помощью @cvuorinen_example.translator .

Впрыскивать все вещи

До сих пор я рассмотрел только «базовый» метод инъекции, конструктор инъекций . Служебный контейнер Symfony также можно использовать с инжекцией сеттера и инжекцией свойства .

Внедрение сеттера означает, что у класса обслуживания есть отдельный метод сеттера для зависимости (потому что он может быть необязательным, например). Это можно настроить, добавив параметр calls в конфигурацию службы, которая представляет собой массив вызовов методов, которые будут выполнены после создания службы. Внедрение свойства означает, что класс имеет открытые свойства, и зависимость может быть установлена ​​в него извне. Это может быть достигнуто с помощью параметра properties в конфигурации сервиса. Более подробную информацию о различных типах впрыска можно найти в документации .

Конфигурация службы также может использовать другую службу в качестве фабрики для создания службы. Фабрика может быть другим сервисом внутри вашего собственного пакета, но вы также можете использовать эту функцию с некоторыми существующими сервисами. Одним из примеров является то, что если вашей службе требуется определенный репозиторий Doctrine, вместо внедрения службы диспетчера сущностей вы можете использовать службу диспетчера сущностей в качестве фабрики для определения класса репозитория как службы. Таким образом, вашему классу обслуживания нужно только добавить зависимость к классу репозитория, а не весь менеджер сущностей. Это делает сервис более переносимым и более легко тестируемым, поскольку вам нужно будет только смоделировать класс репозитория.

Услуги также могут быть объявлены частными. Это означает, что они не будут доступны из контейнера с использованием метода get, их можно использовать только в качестве аргументов, введенных в другие службы. Это можно сделать, установив public: false в конфигурации сервиса.

Вот последний пример, который показывает, как мы можем определить хранилище сущностей как сервис, используя менеджер сущностей Doctrine в качестве фабрики, и внедрить его в другой сервис, используя внедрение сеттера . Служба репозитория сущностей также объявляется частной, поэтому она не будет доступна через контейнер.

 parameters : cvuorinen_example . item_repository . class :   Doctrine \ORM\EntityRepository cvuorinen_example . item_repository . entity :   "CvuorinenExampleBundle:Item" cvuorinen_example . items . class :   Cvuorinen \ExampleBundle\Service\Items services : cvuorinen_example . item_repository : 
         class :   % cvuorinen_example . item_repository . class % 
         public :   false factory_service :  doctrine . orm . entity_manager factory_method :  getRepository arguments :   [% cvuorinen_example . item_repository . entity %] cvuorinen_example . items : 
         class :   % cvuorinen_example . items . class % calls : 
             -   [ setRepository ,   [ @cvuorinen_example . item_repository ]] 

Вывод

Это оказалось довольно длинным постом, и в конфигурации пакета Symfony и контейнере внедрения зависимостей есть еще много чего, что я не рассмотрел. Надеюсь, это поможет вам немного лучше понять систему комплектов Symfony и побудит вас больше использовать внедрение зависимостей. Я надеюсь затронуть более сложные темы в следующих статьях, таких как переопределение конфигурации пакета (наследование пакета), совместное использование параметров между пакетами и определение контроллеров как сервисов.

А пока вы можете больше узнать о контейнере службы и внедрении зависимостей из документации Symfony.

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