Сервис-контейнер¶

Вызов и использование сервисов¶

В тот момент, когда вы запускаете приложение Symfony, ваш контейнер уже содержит много сервисов. Они очень похожи на инструменты: ждут, пока вы восползуетесь ими. В вашем контроллере, вы можете "запросить" сервис из контейнера, путем типизирования аргумента с классом сервиса или именем интерфейса. Хотите сохранить что-то в журнал? Не проблема:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// src/AppBundle/Controller/ProductController.php
// ...

use Psr\Log\LoggerInterface;

/**
 * @Route("/products")
 */
public function listAction(LoggerInterface $logger)
{
    $logger->info('Look! I just used a service');

    // ...
}

Какие еще сервисы существуют? Узнайте, запустив:

1

$ php bin/console debug:container

Это только маленький образец того, что вы увидите:

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

// src/AppBundle/Controller/ProductController.php
namespace AppBundle\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\Controller;

class ProductController extends Controller
{
    /**
     * @Route("/products")
     */
    public function listAction()
    {
        $logger = $this->container->get('logger');
        $logger->info('Look! I just used a service');

        // ...
    }
}

Запрос сервиса напрямую из контейнера таким образом работает только при расширении класса Controller.

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

Создание/конфигурация сервисов в контейнере¶

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

// src/AppBundle/Service/MessageGenerator.php
namespace AppBundle\Service;

class MessageGenerator
{
    public function getHappyMessage()
    {
        $messages = [
            'You did it! You updated the system! Amazing!',
            'That was one of the coolest updates I\'ve seen all day!',
            'Great work! Keep going!',
        ];

        $index = array_rand($messages);

        return $messages[$index];
    }
}

Поздравляем! Вы только что создали ваш первый класс сервисов! Вы можете использовать его сразу же в вашем контроллере:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

use AppBundle\Service\MessageGenerator;

public function newAction(MessageGenerator $messageGenerator)
{
    // благодаря типизированию, контейнер вызовет
    // новый и передаст его вам!
    // ...

    $message = $messageGenerator->getHappyMessage();
    $this->addFlash('success', $message);
    // ...
}

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

Вы также можете вызвать сервис напрямую из контейнера с помощью его "id", которыйru будет его классом имени в нашем случае:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

use AppBundle\Service\MessageGenerator;

// получение доступа к сервисам таким образом работает только,
// если вы расширите контроллер
class ProductController extends Controller
{
    public function newAction()
    {
        // only works if your service is public
        $messageGenerator = $this->get(MessageGenerator::class);

        $message = $messageGenerator->getHappyMessage();
        $this->addFlash('success', $message);
        // ...
    }
}

Однако, это работает только если вы сделате ваш сервис общедоступным.

Внедрение сервисов/конфигурации в сервис¶

Что, если вам нужно получить доступ к сервису logger из MessageGenerator? Ваш сервис не имеет прямого доступа к контейнеру, так что вы не можете вызвать его через $this->container->get().

Не проблема! Вместо этого, создайте метод __construct() с аргументом $logger, который имеет типизирование LoggerInterface. Установите это на новом свойстве $logger и используйте его позже:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

// src/AppBundle/Service/MessageGenerator.php
// ...

use Psr\Log\LoggerInterface;

class MessageGenerator
{
    private $logger;

    public function __construct(LoggerInterface $logger)
    {
        $this->logger = $logger;
    }

    public function getHappyMessage()
    {
        $this->logger->info('About to find a happy message!');
        // ...
    }
}

Вот и все! Контейнер автоматически будет знать, что ему надо передать сервис logger при загруке MessageGenerator. Откуда он это знает? Autowiring. Ключом является титпизирование LoggerInterface в вашем методе __construct() и конфигурация autowire: true в services.yml. Когда вы типизируете аргумент, контейнер будет автоматически искать соответствующий сервис. Если это не удастся, вы увидите явное исключение с предложением помощи.

Как вам знать, что стоит использовать LoggerInterface для типизирования? Вы можете либо прочитать документы для той функции, что вы используете, или получить список автоматического типизирования, вызвав:

1

$ php bin/console debug:container --types

Это только малая часть того, что вы увидите:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

// src/AppBundle/Updates/SiteUpdateManager.php
namespace AppBundle\Updates;

use AppBundle\Service\MessageGenerator;

class SiteUpdateManager
{
    private $messageGenerator;
    private $mailer;

    public function __construct(MessageGenerator $messageGenerator, \Swift_Mailer $mailer)
    {
        $this->messageGenerator = $messageGenerator;
        $this->mailer = $mailer;
    }

    public function notifyOfSiteUpdate()
    {
        $happyMessage = $this->messageGenerator->getHappyMessage();

        $message = \Swift_Message::newInstance()
            ->setSubject('Site update just happened!')
            ->setFrom('[email protected]')
            ->setTo('[email protected]')
            ->addPart(
                'Someone just updated the site. We told them: '.$happyMessage
            );
        $this->mailer->send($message);

        return $message;
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

use AppBundle\Updates\SiteUpdateManager;

public function newAction(SiteUpdateManager $siteUpdateManager)
{
    // ...

    $message = $siteUpdateManager->notifyOfSiteUpdate();
    $this->addFlash('success', $message);
    // ...
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

// src/AppBundle/Updates/SiteUpdateManager.php
// ...

class SiteUpdateManager
{
    // ...
+    private $adminEmail;

-    public function __construct(MessageGenerator $messageGenerator, \Swift_Mailer $mailer)
+    public function __construct(MessageGenerator $messageGenerator, \Swift_Mailer $mailer, $adminEmail)
    {
        // ...
+        $this->adminEmail = $adminEmail;
    }

    public function notifyOfSiteUpdate()
    {
        // ...

        $message = \Swift_Message::newInstance()
            // ...
-            ->setTo('[email protected]')
+            ->setTo($this->adminEmail)
            // ...
        ;
        // ...
    }
}

Параметры сервиса¶

В дополнение к объектам сервиса, контейнер также содержит конфигурацию, под названием parameters. Чтобы создать параметр, добавьте его под ключом parameters и сошлитесь на него с помощью синтаксиса %parameter_name%:

На самом деле, как только вы определите параметр, на него можно сослаться с помощью синтаксиса %parameter_name% в любом другом файле конфигурации сервиса - типа config.yml. Многие параметры определены в parameters.yml file.

Вы также можете вызвать параметры напрямую из контейнера:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

public function newAction()
{
    // ...

    // это работает ТОЛЬКО если вы расширите контроллер
    $adminEmail = $this->container->getParameter('admin_email');

    // или более короткий путь!
    // $adminEmail = $this->getParameter('admin_email');
}

Чтобы узнать больше о параметрах, см /service_container/parameters.

Выбор особенного сервиса¶

Сервис MessageGenerator, созданные ранее, требует аргумент LoggerInterface:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// src/AppBundle/Service/MessageGenerator.php
// ...

use Psr\Log\LoggerInterface;

class MessageGenerator
{
    private $logger;

    public function __construct(LoggerInterface $logger)
    {
        $this->logger = $logger;
    }
    // ...
}

Однако, существует множество сервисов в контейнере, которые имплементируют LoggerInterface, например, logger, monolog.logger.request, monolog.logger.php, и др. Как контейнер знает, какие использовать?

В таких ситуациях, контейнер обычно сконфигурирован так, чтобы автоматически выбирать один из сервисов - в этом случае logger (узнайте больше, почему в Использование дополнительных имён для включения автомонтирования). Но,вы можете контролировать это и передать другой logger:

Это сообщает контейнеру, что аргумент $logger для __construct должен использовать сервис, id которого monolog.logger.request.

Опция автоподключения¶

Выше, файл services.yml имеет autowire: true в разделе _defaults,так что это относится ко всем сервисам, определенным в этом файле. С этой настройкой, вы можете типизировать аргументы в методе __construct() ваших сервисов и контейнер автоматически будет передавать вам правильные аргументы. Эта вся запись была написана без автоматизации.

Чтобы узнать больше, см Defining Services Dependencies Automatically (Autowiring).

Опция автоконфигурации¶

Выше, файл services.yml имеет autoconfigure: true в секции _defaults, так что это относится ко всем сервисам, определенным в этом файле. С этой настройкой, контейнер будет автоматически применять определенную конфигурацию к вашим сервисам, основываясь на классе вашего сервиса. Это чаще всего используется для авто-тегирования ваших сервисов.

Например, чтобы создать Twig Extension (Расширение Twig), вам нужно создать класс, зарегистрировать его в качестве сервиса, и тегировать его twig.extension:

Однако с autoconfigure: true, вам не нужен тег. На самом деле, если вы используете Symfony Standard Edition services.yml config, вам не нужно ничего делать: сервис будет загружен автоматически. Потом, autoconfigure добавит тег twig.extension за вас, так как вас класс имплементирует Twig_ExtensionInterface. И благодаря``autowire``, вы даже можете добавить аргументы-конструкторы без какой-либо конфигурации.

Конечное же, вы все еще можете сконфигурировать сервис вручную, если вам это нужно.

Публичные сервисы против приватных¶

Благодаря разделу _defaults в services.yml, каждый сервис, определенный в этом файле, public: false по умолчанию:

Что это значит? Когда сервис не публичен, вы не можете получить к нему доступ напрямую из контейнера:

1
2
3
4
5
6
7
8
9

use AppBundle\Service\MessageGenerator;

public function newAction(MessageGenerator $messageGenerator)
{
    // типизирование его в качестве аргумента РАБОТАЕТ

    // но доступ к нему напрямую из контейнера НЕ работает
    $this->container->get(MessageGenerator::class);
}

Обычно это нормально: существуют лучшие способы получить доступ к сервису. Но, если вам надо сделать ваш сервис публичным, просто перепишите эту установку:

Одномоментный импорт множества сервисов с помощью источника¶

Вы уже видели, что вы можете импортировать множество сервисов одновременно, используя ключ resource. Например, конфигурация Symfony по умолчанию, содержит следующее:

Это может быть использовано для того, чтобы быстро сделать много классов доступными в качестве сервисов, и применить какую-то конфигурацию по умолчанию. Id каждого сервиса - это его полностью квалифицированное имя класса. Вы можете переписать любой сервис, который был испортирован, используя его id (имя класса) ниже (например, см. Подключение аргументов вручную). Если вы перепишите сервис, никакие из опций (например, public) не будут унаследованы из импорта (но переписанный сервис наследует из _defaults).

Вы также можете exclude (исключить) определенные пути. Это не обязательно, но слегка увеличит производительность окружения dev: исключенные пути не отслеживаются, так что их изменение не приведет к перестройке контейнера.

Ясная конфигурация сервисов и аргументов¶

До появления Symfony 3.3, все сервисы и (обычно) аргументы, были ясно сконфигурированы: было невозможно загрузить сервисы автоматически и автоподключение было намного менее распространено.

Обе эти функции не обязательны. И даже если вы используете их, могут быть некоторые случае, когда вы захотите вручную подключить сервис. Например, представьте, что вы хотите зарегистрировать 2 сервиса для класса SiteUpdateManager - каждый с разным email админа. В этом случае, каждый должен иметь уникальный id сервиса:

В этом случае, два сервиса зарегистрированы: site_update_manager.superadmin и site_update_manager.normal_users. Благодаря союзнику, если вы типизируете SiteUpdateManager будет передано первое (site_update_manager.superadmin). Если вы хотите передать второе, то вам нужно вручную подключить сервис.

Узнайте больше¶