Как использовать события в ZF2/3?

Question

[Сергей Поздняков]

Доброго времени суток!
Подскажите пожалуйста, как правильно подписываться на события и в каком месте. В интернете кучу примеров с Foo bar, но они не дают ни какого понятия как это использовать в реальных проектах.
Например, у меня есть изменение заказа. В бустрапе модуля сделал так

$sharedEventManager->attach(
            Mapper\Order::class,
            AbstractMapper::EVENT_INSERT_ENTITY,
            function ($e) use ($serviceManager) {
                /** @var \Office\Service\Order $orderService */
                $orderService = $serviceManager->get(Service\Order::class);
                $entity = $e->getParam('entity');
                if ($entity) {
                    $orderService->addOrderLog($entity, Entity\Order\LogAction::CREATED);
                }
            }
        );

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

Далее, в сервисе возникает куча событий на создание/изменение/доставку и т.д. заказа. Почитал мануал, надо делать агрегатор событий для подписки кучей.
Сделал. Подписка происходит так.

/**
     * @param EventManagerInterface $events
     */
    public function attach(EventManagerInterface $events)
    {
        $this->listeners[] = $events->attach(
            Order::EVENT_ERROR_CONFIRM_ORDER, [
                $this,
                'sendErrorConfirmOrder'
            ]
        );
        $this->listeners[] = $events->attach(
            Order::EVENT_CONFIRM_ORDER, [
                $this,
                'okConfirmOrder'
            ]
        );
    }

Но как делать установку агрегатора? Если событие возникает в нескольких контроллерах, то нужно в их фабриках прописать что-то такое
$class->getEventManager()->attach($agregator);
Не совсем гибко, забыл добавить установку - события в луну ушли. А мне нужно их между модулями перекидывать.
Попробовал опять SharedEventManager, но тогда в бустрапе получается огромное полотно кода с function ($e) use ($serviceManager) {
Что не красиво и не удобно. Как правильно делать? Где можно посмотреть?

Answer 1

[novrm]

Вам нужно понять главный смысл событий в ZF3 - нужно создавать ОТДЕЛЬНЫЙ ИНДИВИДУАЛЬНЫЙ экземпляр EventManager для каждой группы событий.
... и потом извлекать события из этого же ИНДИВИДУАЛЬНОГО EventManager*а.
То есть фишка с одним EventManager для ВСЕГО проекта - это путь в тупик.

Comments

[Сергей Поздняков]

"ИНДИВИДУАЛЬНЫЙ EventManager" у меня создается в каждом контроллере/маппере/сервисе. Как я понял это сделано для повышения производительности - индивидуальные event manager'ы.
Но как мне извлечь эти события? Они же привязаны к конкретному классу. У меня есть модуль заказов и модуль отправки сообщений.
Раньше я через сервис локатор делал вызов сервиса из соседнего модуля. А вот теперь решил попробовать по модному - через события....
Работает только 1 вариант, как я писал выше - это в фабрике прикреплять агрегатор событий в event manager созданного класса. Это правильно?

[novrm]

Сергей Поздняков,
1. Есть модуль.
2. В нем создаете класс - свой EventManger.
3. Дальше используете этот класс везде, где нужно.

Как использовать - путей может быть много.

Итак пример из жизни.
Вот у вас модуль ZfcUser.

Вот класс - который индивидуальный EventManager: \ZfcUser\EventManager\EventProvider
Его можете взять, как стандарт для индивидуального EventManager*a.

Идем дальше этот класс наследует опорный сервис для ZfcUser - класс \ZfcUser\Service\User

Здесь или здесь используется система событий...

Как это можно применить в народном хозяйстве.
Объясняю на конкретном примере.
Модуль ZfcUser он регистрирует пользователя, но не присваивает ему никакой роли - типа user или admin или еще что-то.
Ролями занимается другой модуль. Например BjyAuthorize.
Детали долго рассказывать - приведу код, как используя систему событий ZfcUser установить новому пользователю при регистрации роль user по умолчанию автоматически.

В конфигурации service_manager - прикрепляем делегатор:

return [
    /** Zend Framework component configurations. */
    'service_manager' => [
        'delegators' => [
            'zfcuser_user_service' => [\Fork\ZfcUserDoctrineORM\Service\Delegator\AddDefaultRoleForRegisteredUserDelegator::class],
        ],
    ]
];

Код делегатора:

<?php
/**
 * Zend Framework Application.
 *
 * @since 11:21 20.09.2017
 */

namespace Fork\ZfcUserDoctrineORM\Service\Delegator;

use Interop\Container\ContainerInterface;
use Zend\ServiceManager\Factory\DelegatorFactoryInterface;

/**
 * AddDefaultRoleForRegisteredUserDelegator delegator.
 *
 * Configure instance of \ZfcUser\Service\User.
 *
 * @package Fork\ZfcUserDoctrineORM\Service\Delegator
 */
class AddDefaultRoleForRegisteredUserDelegator implements DelegatorFactoryInterface
{

    /**
     * {@inheritDoc}
     *
     * @link   https://github.com/ZF-Commons/ZfcUser/wiki/How-to-store-custom-form-values-into-your-user-entity-at-registration
     * @return \ZfcUser\Service\User
     */
    public function __invoke(ContainerInterface $container, $requestedName, callable $callback, array $options = null)
    {                           /** Retrieve services. */
        $zfcUserServiceUser             = call_user_func($callback);
        $entityManager                  = $container->get('Doctrine\ORM\EntityManager');
        $zfcUserServiceUserEventManager = $zfcUserServiceUser->getEventManager();
                                /** Attach event for add default role. */
        $zfcUserServiceUserEventManager->attach('register', function($mvcEvent) use ($entityManager) {
            $user = $mvcEvent->getParam('user');
                                /** Fetched 'user' role as in DB. */
            $role = $entityManager->getReference('Database\Entity\Role', 2);
                                /** Set for user the role user. */
            $user->addRole($role);

            $mvcEvent->setParam('user', $user);
        });
        return $zfcUserServiceUser;
    }

}

Короткий коментарий.
Строчкой

$zfcUserServiceUserEventManager = $zfcUserServiceUser->getEventManager();

мы получаем индивидуальный EventManager.
А строчкой:

$zfcUserServiceUserEventManager->attach('register', function($mvcEvent) use ($entityManager) {
            $user = $mvcEvent->getParam('user');
                                /** Fetched 'user' role as in DB. */
            $role = $entityManager->getReference('Database\Entity\Role', 2);
                                /** Set for user the role user. */
            $user->addRole($role);

            $mvcEvent->setParam('user', $user);
        });

прикрепляем к событию 'register' код, который установит роль user - 2 ЕЩЕ до момента отправки в БД.

[Сергей Поздняков]

novrm, Большое спасибо от народного хозяйства)
Я как-то забыл про делегаторы. Похоже это то, что мне надо.

Answer 2

[Fortop]

Во-первых, задача событий как раз уход в луну.
На событиях вы реализуете или расширение основного функционала или работу необязательных для основного потока вещей.

Это снимет массу головной боли и сейчас при отладке и в будущем.

Во-вторых, подписываться на события правильно на этапе инициализации приложения.
Это может быть бутстрап приложения, бутстрап модуля, в момент инициализации конкретного сервиса.

Comments

[Сергей Поздняков]

У меня есть отправка уведомлений, раньше я ее делал через вызов сервиса с соответствующим методом.
Но если у меня кроме отправки на почту уведомления уходят еще в вайбер? Я решил сделать события.

Варианты подписки:
1. В фабрике каждого сервиса где будет вызов. Но тут как мне кажется не очень удобно, надо помнить какие события вызываются, либо делать агрегатор для подписки пачкой. Но опять же надо его тогда пихать почти в каждую фабрику.
2. Подписка в модуле. Сделал так

$sharedEventManager->attach(
            '*',
            Order::EVENT_CONFIRM_ORDER,
            function ($e) use ($serviceManager) {
                /** @var OfficeSender $officeSender */
                $officeSender = $serviceManager->get(OfficeSender::class);
                $officeSender->sendErrorConfirmOrder($e);
            }
        );

В доках пишут, что не надо использовать много расшаренных подписок, так как приложение будет тормозить. Постом выше novrm описал это.

Вот я и не знаю по какому пути пойти.

[Fortop]

Но если у меня кроме отправки на почту уведомления уходят еще в вайбер? Я решил сделать события.

Ну и ок.

Основной поток может же продолжать работать без уведомлений. Поэтому на событиях нормальное решение.

1. В фабрике каждого сервиса где будет вызов. Но тут как мне кажется не очень удобно, надо помнить какие события вызываются

interface InitAware {
    public function init();
}

function Factory(InitAware $className) {
    $service = new $className;
    $service->init(); // тут мы подписываемся на события
    return $service;
}