> необходимость в сервисах в сущностях сначала решаем дабл диспатчем

Question

> необходимость в сервисах в сущностях сначала решаем дабл диспатчем

и потом переходим на доменные ивенты

Получается, что сущность делается слушателем неких событий по такой же схеме, как и обычные event listener’ы (типа симфоневских)? Или в данном случае какая-то другая технология?

#russian #software #symfony

0

24.02.2019

2 ответов

4 просмотра

Sergey P

не совсем. @andrewDemb в целом объяснил в чем различие. Идея в том что сущность сама по себе не знает когда транзакция завершена, так же у нее нет возможности "пробросить события на обработку", это все делигируется какой-то координирующей логике наверху. В случае с той же доктриной можно слушать postFlush событие и собирать ивенты там. Если юзаешь что-то другое - находишь точку когда транзакция завершена и ивенты собранные сущностями превращаются в факты. Если хочешь ивенты хранить - имеет смысл собирать их по preFlush, записывать в базу, делатьь коммит и по postFlush кидать их на обработку. Или, что прикольнее, иметь отдельный демон который смотрит на стрим всех ивентов и просто идет по курсору. Добавились новые события - он их обработает (типа что бы гарантировать последовательность действий) но тогда тебе придется забыть о таких вещах как "сделал дело - выкинул респонс", то есть синхронизация стэйта на клиенте должна происходить как-то асинхронно. Например через вэб сокеты (в целом это логично и я бы сказал что в разы лучше чем другие варианты)

0

24.02.2019

Andrii Dembitskyi · Accepted Answer

Andrii Dembitskyi

Сущность события собирала бы в себе, и по запросу отдавала бы их. Дальше, куда они пойдут, её не заботит

0

24.02.2019

52 похожих чатов

> необходимость в сервисах в сущностях сначала решаем дабл диспатчем

2 ответов

Похожие вопросы