У меня нет большого практического опыта в этой теме, но, поскольку никто больше не отвечает, я полагаю, я поделюсь своим мнением об этом ...
Возможно, это немногосложная вещь в PHP-приложениях, поскольку они обычно работают только на время запроса, поэтому преимущество возможности подписываться и прослушивать общие события на этом коротком этапе может быть не очень большим.
Однако яЯ думаю, что есть некоторые преимущества в том, что вы можете больше отделять свой код.
Из того, что я могу сказать, диспетчер Symfony выглядит лучше - в основном потому, что он выглядит проще.
Я использовалЧто-то вроде системы типов dojo pubsub : по сути, у вас есть издатель событий, которому классы могут публиковать события.Это своего рода глобальная обработка событий, когда вы специально не подписываетесь на сам класс - вместо этого вы подписываетесь на определенное событие, и не имеет значения, какой класс публикует событие.
Преимуществаэто по сравнению с подпиской на определенный класс состоит в том, что код больше отделен: в моем случае это приложение ZF, и классы, которые подписываются на события, могут просто сделать это в начальной загрузке, вместо того, чтобы делать подписки в контроллерах (или гдекогда бы ни создавались издатели)
Недостатком этого подхода является то, что он может усложнить отслеживание зависимостей между вещами.Например, вы видите только вызов публикации события, но вы не представляете, какие вещи его слушают, не углубляясь в код.
В моем случае я действительно не знаю, есть ли в приложении какое-либо приложение.Преимущества использования этой архитектуры - на самом деле я несколько раз думал об ее полном удалении и просто об использовании объектов, которые непосредственно слушают события.