События и наблюдатели
Использование событий объекта для снижения связанности кода. Способы генерации событий и пути подписки на них сторонних слушателей. Запуск событий непосредственно в объекте и в общем диспетчере. Накопление событий в объекте для работы с транзакциями базы данных.
Скрытый контент (код, слайды, ...) для подписчиков. Открыть →
Дмитрий Елисеев
elisdn.ru
Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Впринципе норм объяснения, но заметил, что много функций php используемых в этом уроке, я попросту вижу впервые или не помню. Что особенно непонятно - свойство $this->listeners; Откуда оно взялось ? В документации пыха не нашел такое.
listeners в данном случае это свойство класса UserImporter которое мы сами создали. Читать тут
Когда выйдет следующее видео из серии?
На gitHub можно конечный результат из урока посмотреть?)
К этим эпизодам кода нет.
Очень интересно! Спасибо, Дмитрий!
Дмитрий, спасибо большое за ваш труд. У вас прекрасные курсы. Не останавливайтесь)
Еще бы Дмитрий закончил начатое дело
елки не туда вопрос написал) надо как-то поменять. Как быть если есть два инстанса условно UserImporter и разные обработчиеи должны быть?
Каждому инстансу передаём нужные ему обработчики. Либо если обработчики общие, то работу с событиями можно вынести в отдельный класс EventDispatcher с обработчиками и всем инстансам передаём диспетчер.
Получается придется в нужный объект добавляем метод для подписки. Верно?
Да, каждому.
А следующее видео будет?
Апдейт: странный тайтл отправился, не обращайте внимания на него
Ждем Decorator, Pipeline!!! Спасибо =)
Дмитрий, добрый день, а когда вы планируете выпустить шестой эпизод по ООП:Взаимодействие объектов? Было бы очень полезно закончить, думаю многие ждут.
как же я рад что нашел тебя , мой наставник!!!
Все действия Event'ов - фактически ReadOnly, они не могут изменять поведение сервиса?
Пример:
У нас есть OrderService для создания заказов. Мы ввели BlacklistService для анализа данных заказа, и блокировки некоторых из них (при этом сохраняем заказ в БД, просто со статусом "Blocked").
Где мы должны использовать BlacklistService?
1) Использовать BlacklistService внутри OrderService.
2) Навесить BlacklistService на событие OrderService.
3) Использовать результат выполнения OrderService "снаружи", передавая их в BlacklistService.
4) Другое: ...
События появляются уже после завершения какого-то действия, а не до или во время. Поэтому если событие нужно сделать посредине, то большую операцию нужно разбить на несколько этапов, которые будут выполняться друг за другом.
Если это именно распределённая система из модулей или микросервисов, общающаяся по событиям, то использовать отдельно.
Если взять этот ваш пример, то вместо непосредственного создания заказов со статусами Active и Blocked достаточно сначала создать заказ со статусом Pending. И уже потом Blacklist ловит событие OrderPending, анализирует данные и генерирует свои события Approved или Blocked, по которым вызываются команды Activate или Block переключения заказа.
Я так понимаю 6 эпизод не появится никогда))
Спасибо, Дмитрий! Отлично. Тайм коды в будущем не помешали бы :)
А вопрос такой: насколько детальный код (который выполняет реальную работу) резонно размещать в event subscribers?
То есть чем subscribers будут отличаться от сервисов в части исполнения черновой работы.
Например, каскадное транзакционное удаление записей в нескольких таблицах по событию можно организовать двумя способами (в моей голове так, по крайней мере):
1) Создать класс сервиса, который подтягивает из контейнера нужные репозитории и выполняет каскадное удаление. И метод этого сервиса вызывать из метода subscriber-а, чтобы он дергался по событию.
2) репозитории и код каскадного удаления запихать сразу в метод subscriber-а.
Какой из подходов гибче и больше экономит силы на длинных дистанциях?
Лучше слушатель делать легковесным, который слушает события и отправляет команды.
Или войти через: