Зачем нужны события в yii2?

Question

[xbcaax]

Есть ли смысл использовать свои events в yii2? Не легче вызвать нужный метод оттуда где мы вешаем триггер? Элегантый код?

Answer 1

[MegaMufa]

Событийная модель помогает строить слабосвязанную систему. Пример из жизни. Я сейчас работаю над SAAS платформой. Компания покупает учетку и выбирает за какие модули платить. Есть модули учета, проверок, для кадровиков и т.д. Модули должны взаимодействовать между собой, но любого модуля может не быть.

Например при создании сотрудника в модуле "кадррезерв", его автоматически надо добавить в модуль "учета". Я не могу напрямую дергать метод из другого модуля т.к. заранее не известно, будет он куплен или нет.

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

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

Comments

[Сергей Протько]

проблема не в слишком слабой связанности а в недостаточном зацеплении (coheashing) и сложностях в дебаге и покрытии тестами. По сути логику на ивентах невозможно нормально замокать, потому только функциональные тесты.

[MegaMufa]

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

[Сергей Протько]

HaruAtari: ну я правильно понимаю что вы мокаете диспатчер или что-то в этом духе, так?

[Павел Волынцев]

Сергей Протько: Правильный диспетчер событий, основанный на Inversion of Control, позволяет заменить внутри себя всё, что надо. Логично, что должен быть отдельный тест для проверки работы диспетчера на базе тестовых событий и моков, позволяющих проверить внутренности классов.

[MegaMufa]

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

Само взаимодействие модулей (реацию на события) мы тестируем приемочными тестами. Думаю. это логично, ведь тут уже рассматривается пользовательский сценарий.

[Сергей Протько]

HaruAtari: я не говорю о тестировании диспетчера событий, я про то что приходится мокать диспетчер что бы отследить какие ивенты были сгенерированы системой. Это нормальная практика, особенно когда ивенты генерятся сервисами. Я же использую domain events, разница в этом подходе лишь в том что мне не надо мокать диспетчер, так как он дергается только по postFlush доктрины, тогда из всех сущностей учавствовавших в транзакции (а точнее все что лежит в UoW) забираются все события которые произошли с моделью. А значит в тестах я могу получить список этих ивентов как обычный массив просто вызвав метод модели.

[MegaMufa]

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

[Kronus77]

HaruAtari, насчет указанного вами примера почти всё ясно, и очевидны плюсы такого подхода, но не понятен один момент: где вешать обработчик на событие user.created? Если вешать в модели User, то получается зависимость (от другого модуля). Если же вешать в другом модуле, то не сработает, поскольку они не загружены в память.

[MegaMufa]

Kronus77: Да. Отложенная загрузка модулей сильно мешает. Мы при инициализации приложения пробегаемся по списку модулей и вызываем у каждого статичный метод setEventHandlers(). Из-за того, что метод статичный инициализация модуля не требуется. Не очень красиво, но работает.

Answer 2

[LAV45]

Эта и многие другие темы по yii2 на пальцах, и на русском языке ))
https://www.youtube.com/user/ElisDN/videos

Answer 3

[Mikhail Osher]

К примеру, есть событие "создан пользователь".
На него вешают обработчики "отправить смс туда-то", "отправить ивэнт в какой-нибудь микс-пэнел", "подготовить какие-либо имэйлы для юзера".
Чтобы не говнокодить всё в одном месте - разделено все по логичным сервисам.

Comments

[Сергей Протько]

Как фанат DDD вставлю свои 3 копейки, событие "пользователь создан" должно зафаириться только после того как пользователь действительно был создан, транзакция в базу пошла успешно и т.д. То есть либо из сервисного слоя либо domain events но это не про Yii2

[MegaMufa]

Сергей Протько: я для этого с модели делаю метод create() в нем провожу валидацию, сохранение и бросаю событие. Сервисов в yii очень не хватает, призодится костылить.

[Сергей Протько]

HaruAtari: в Yii2 вроде ж запилили нормальный IoC аля Laravel... мне кажется кастыли идут от AR а не от Yii.

[MegaMufa]

Сергей Протько: Да, вы правы. Это подход AR, а не Yii. Но т.к. Yii пропагандирует AR, у меня возникла именно такая ассоциация. Я пробовал использовать Yii вместе с Doctrine - то еще удовольствие.
Подход к работе с моделями - это все-таки часть идеалогии фреймврка. Раз создатели выбрали AR, то стоит использовать именно ее. В противном случае, проще сменить фреймворк. Хотя бы потому, что большинство комьюнити пользуется дефолтным средством и помошь по чему-то специфичному будет найти трудно.

[amiak]

Mikhail Osher вызывать нужные методы из логичных сервисов = говнокод? Смысл использовать здесь ивенты?

Answer 4

[Никита]

Все достаточно просто. С помощью ивентов можно дописывать функционал не затрагивает чужой код. Это добавляет гибкости в модульности.
В частности посмотрите на сторонние Behaviors, они очень ярко показывают суть вопроса.