Задонатить и смотреть →
Открыть доступ к сотне полезных скринкастов

События и наблюдатели

Использование событий объекта для снижения связанности кода. Способы генерации событий и пути подписки на них сторонних слушателей. Запуск событий непосредственно в объекте и в общем диспетчере. Накопление событий в объекте для работы с транзакциями базы данных.

Скрытый контент (код, слайды, ...) для подписчиков. Открыть →
Дмитрий Елисеев
elisdn.ru
Комментарии (21)
Александр

Впринципе норм объяснения, но заметил, что много функций php используемых в этом уроке, я попросту вижу впервые или не помню. Что особенно непонятно - свойство $this->listeners; Откуда оно взялось ? В документации пыха не нашел такое.

Ответить
voodooism

listeners в данном случае это свойство класса UserImporter которое мы сами создали. Читать тут

Ответить
Райымбек

Когда выйдет следующее видео из серии?

Ответить
Андрей

На gitHub можно конечный результат из урока посмотреть?)

Ответить
Дмитрий Елисеев

К этим эпизодам кода нет.

Ответить
Paul

Очень интересно! Спасибо, Дмитрий!

Ответить
Артём

Дмитрий, спасибо большое за ваш труд. У вас прекрасные курсы. Не останавливайтесь)

Ответить
Дмитрий

Еще бы Дмитрий закончил начатое дело

Ответить
Виктор

елки не туда вопрос написал) надо как-то поменять. Как быть если есть два инстанса условно UserImporter и разные обработчиеи должны быть?

Ответить
Дмитрий Елисеев

Каждому инстансу передаём нужные ему обработчики. Либо если обработчики общие, то работу с событиями можно вынести в отдельный класс EventDispatcher с обработчиками и всем инстансам передаём диспетчер.

Ответить
Виктор

Получается придется в нужный объект добавляем метод для подписки. Верно?

Ответить
Дмитрий Елисеев

Да, каждому.

Ответить
Дмитрий, а есть смысл дробить саму сущность пользователя относительно контекста определенных действий или это совсем избыточно? Вы как-то ввели flusher для того чтобы ограничить возможные действия с em.

А следующее видео будет?

Апдейт: странный тайтл отправился, не обращайте внимания на него

Ответить
Андрей

Ждем Decorator, Pipeline!!! Спасибо =)

Ответить
Кропотов Александр

Дмитрий, добрый день, а когда вы планируете выпустить шестой эпизод по ООП:Взаимодействие объектов? Было бы очень полезно закончить, думаю многие ждут.

Ответить
Анатолий

как же я рад что нашел тебя , мой наставник!!!

Ответить
S.Polessky

Все действия Event'ов - фактически ReadOnly, они не могут изменять поведение сервиса?

Пример:

У нас есть OrderService для создания заказов. Мы ввели BlacklistService для анализа данных заказа, и блокировки некоторых из них (при этом сохраняем заказ в БД, просто со статусом "Blocked").

Где мы должны использовать BlacklistService?

1) Использовать BlacklistService внутри OrderService.

2) Навесить BlacklistService на событие OrderService.

3) Использовать результат выполнения OrderService "снаружи", передавая их в BlacklistService.

4) Другое: ...

Ответить
Дмитрий Елисеев

Они не могут изменять поведение сервиса?

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

Где мы должны использовать BlacklistService?

Если это именно распределённая система из модулей или микросервисов, общающаяся по событиям, то использовать отдельно.

При этом сохраняем заказ в БД, просто со статусом Blocked

Если взять этот ваш пример, то вместо непосредственного создания заказов со статусами Active и Blocked достаточно сначала создать заказ со статусом Pending. И уже потом Blacklist ловит событие OrderPending, анализирует данные и генерирует свои события Approved или Blocked, по которым вызываются команды Activate или Block переключения заказа.

Ответить
lambdahhh

Я так понимаю 6 эпизод не появится никогда))

Ответить
Владимир Перепеченко

Спасибо, Дмитрий! Отлично. Тайм коды в будущем не помешали бы :)

А вопрос такой: насколько детальный код (который выполняет реальную работу) резонно размещать в event subscribers?

То есть чем subscribers будут отличаться от сервисов в части исполнения черновой работы.

Например, каскадное транзакционное удаление записей в нескольких таблицах по событию можно организовать двумя способами (в моей голове так, по крайней мере):

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

2) репозитории и код каскадного удаления запихать сразу в метод subscriber-а.

Какой из подходов гибче и больше экономит силы на длинных дистанциях?

Ответить
Дмитрий Елисеев

Какой из подходов гибче и больше экономит силы на длинных дистанциях?

Лучше слушатель делать легковесным, который слушает события и отправляет команды.

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий

Или войти через:

Google
GitHub
Yandex
MailRu