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

У деяких випадках, ви можете захотіти впровадити сервіс, який трохи заважкий для інстанціювання, але не завжди використовується всередині вашого обʼєкта. Наприклад, уявіть, що у вас є 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 $container): void {
    $services = $container->services();

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

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

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

1
2

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

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

1
2
3
4
5
6
7
8
9
10

namespace App\Twig;

use Symfony\Component\DependencyInjection\Attribute\Autoconfigure;
use Twig\Extension\ExtensionInterface;

#[Autoconfigure(lazy: true)]
class AppExtension implements ExtensionInterface
{
    // ...
}

Ви також можете сконфігурувати лінивість, коли ваш сервіс впроваджується за допомогою атрибута Autowire:

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

namespace App\Service;

use App\Twig\AppExtension;
use Symfony\Component\DependencyInjection\Attribute\Autowire;

class MessageGenerator
{
    public function __construct(
        #[Autowire(service: 'app.twig.app_extension', lazy: true)] ExtensionInterface $extension
    ) {
        // ...
    }
}

Цей атрибут також дозволяє вам визначити інтерфейси для проксі при використанні лінивості, і підтримує ліниве автомонтування типів об'єднань:

1
2
3
4
5

public function __construct(
    #[Autowire(service: 'foo', lazy: FooInterface::class)]
    FooInterface|BarInterface $foo,
) {
}

Іншою можливістю є використання атрибута Lazy:

1
2
3
4
5
6
7
8
9
10

namespace App\Twig;

use Symfony\Component\DependencyInjection\Attribute\Lazy;
use Twig\Extension\ExtensionInterface;

#[Lazy]
class AppExtension implements ExtensionInterface
{
    // ...
}

Цей атрибут можна застосовувати як до класу, так і до параметрів, які мають бути ліниво завантажені. Він визначає необов'язковий параметр, який використовується для визначення інтерфейсів для типів проксі та перетину:

1
2
3
4
5

public function __construct(
    #[Lazy(FooInterface::class)]
    FooInterface|BarInterface $foo,
) {
}

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

За лаштунками, проксі, згенеровані для лінивого завантаження сервісів, наслідують з класу, використовуваного сервісом. Однак, іноди це взагалі неможливо (наприклад, через те, що клас - 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 $container): void {
    $services = $container->services();

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

Як і в розділі Конфігурація , ви можете використати атрибут Autoconfigure, щоб сконфігурувати інтерфейс для проксування, передавши його FQCN як значення параметра lazy:

1
2
3
4
5
6
7
8
9
10

namespace App\Twig;

use Symfony\Component\DependencyInjection\Attribute\Autoconfigure;
use Twig\Extension\ExtensionInterface;

#[Autoconfigure(lazy: ExtensionInterface::class)]
class AppExtension implements ExtensionInterface
{
    // ...
}

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