Чому ліниві сервіси?

У деяких випадках, ви можете захотіти впровадити сервіс, який трохи заважкий для інстанціювання, але не завжди використовується всередині вашого обʼєкта. Наприклад, уявіть, що у вас є NewsletterManager і ви впроваджуєте у нього сервіс mailer. Лише декілька методів у вашому NewsletterManager дійсно використовують mailer, але навіть коли він вам не потрібний, сервіс mailer завжди інстанціюється, щоб побудувати ваш NewsletterManager.

Рішенням цього є ліниві сервіси. З лінивим сервісом насправді впроваджується "проксі" сервісу mailer. Він виглядає та поводить себе точно так само, як і mailer, крім того, що mailer насправді не інстанціюється до того як ви почнете якусь взаємодію з проксі.

Конфігурація

Ви можете відмітити сервіс як lazy, змінивши його визначення:

1
2
3
4

# config/services.yaml
services:
    App\Twig\AppExtension:
        lazy: true

1
2
3
4
5
6
7
8
9
10
11

<!-- config/services.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd">

    <services>
        <service id="App\Twig\AppExtension" lazy="true"/>
    </services>
</container>

1
2
3
4
5
6
7
8
9
10

// config/services.php
namespace Symfony\Component\DependencyInjection\Loader\Configurator;

use App\Twig\AppExtension;

return function(ContainerConfigurator $configurator) {
    $services = $configurator->services();

    $services->set(AppExtension::class)->lazy();
};

Як тільки ви впровадите сервіс в інший сервіс має бути впроваджено лінивий обʼєкт-привид з таким же підписом класу, що представляє сервіс. Лінивий обʼєкт-привид - це обʼєкт, який створюється порожнім і який може ініціалізувати сам себе, коли до нього отримують доступ вперше. Теж саме відбувається, якщо викликати Container::get() напряму.

Щоб перевірити, чи працює ваш лінивий сервіс, ви можете перевірити інтерфейс отриманого обʼєкта:

1
2

dump(class_implements($service));
// виведення повинно включати в себе "Symfony\Component\VarExporter\LazyGhostObjectInterface"

Проксування інтерфейсу

За лаштунками, проксі, згенеровані для лінивого завантаження сервісів, наслідують з класу, використовуваного сервісом. Однак, іноди це взагалі неможливо (наприклад, через те, що клас - final і не може бути розширений) або незручно.

Щоб обійти це обмеження, ви можете сконфігурувати проксі, щоб він реалізовував тільки конкретні інтерфейси.

1
2
3
4
5
6
7
8

# config/services.yaml
services:
    App\Twig\AppExtension:
        lazy: 'Twig\Extension\ExtensionInterface'
        # or a complete definition:
        lazy: true
        tags:
            - { name: 'proxy', interface: 'Twig\Extension\ExtensionInterface' }

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

<!-- config/services.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd">

    <services>
        <service id="App\Twig\AppExtension" lazy="Twig\Extension\ExtensionInterface"/>
        <!-- or a complete definition: -->
        <service id="App\Twig\AppExtension" lazy="true">
            <tag name="proxy" interface="Twig\Extension\ExtensionInterface"/>
        </service>
    </services>
</container>

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

// config/services.php
namespace Symfony\Component\DependencyInjection\Loader\Configurator;

use App\Twig\AppExtension;
use Twig\Extension\ExtensionInterface;

return function(ContainerConfigurator $configurator) {
    $services = $configurator->services();

    $services->set(AppExtension::class)
        ->lazy()
        ->tag('proxy', ['interface' => ExtensionInterface::class])
    ;
};

Віртуальний проксі, впроваджений в інші сервіси, реалізовуватиме лише вказані інтерфейси і не розширюватиме оригінальний клас сервісу, що дозволить ліниве завантаження сервісів з використанням класів final. Ви можете сконфігурувати проксі так, щоб він реалізовував декілька інтерфейсів, додавши нові теги "proxy".