I do not have much practical experience in this topic, but since no one else seems to be responding, I believe that I will share what I think about it ...
This is perhaps a bit of a tricky thing in PHP applications, since they usually only work for the duration of the request, so the advantage that you can subscribe and listen to general events during this short phase may not be very large.
However, I think there may be some advantages to letting you split your code more.
From what I can tell, Symfony Dispatcher looks better - mainly because it looks simpler.
I used a kind of dojo pubsub type of system: basically you have an event publisher for which classes can publish events, This is a kind of global event handling in which you do not specifically subscribe to the class itself - instead, you subscribe to a specific event, and It doesn't matter which class publishes the event.
The benefits of this or subscribing to a particular class are that the code is more untied: in my case it’s a ZF application, and classes that subscribe to events can just do it in bootstrap, and not do subscriptions in controllers (or where ever publishers are created)
The disadvantage of this approach is that it can create dependencies between things that are harder to track. For example, you only see the call to publish the event, but you can’t imagine what things are listening to it without delving into the code.
In my case, I really don’t know if the application received any advantages from using this architecture - in fact, I thought about deleting several times completely and simply used objects that listen for events directly.
Jani Hartikainen
source share