Beside the fact that some event handlers (together with their dependencies) may never need to be loaded for the current application run (so why instantiate if they're never used? ... one of the DI advantages is instantiation on demand), the biggest problem appears when the number of event listeners becomes large.
In my particular case I have a domain model that publishes an event with each operation/action. This event is then used by multiple listeners which are in fact application services: - an event store service that logs all events to the DB - it will depend on a Db instance - a mailing service that generates and sends emails on certain events - it will depend on a Mailer instance and a Db instance - application services that use the event data to apply changes to other domain aggregates(entities) - they will depend on domain repositories and other application services The number of listeners is directly proportional with my domain model's size and complexity, and while you may argue that some of these listeners are always needed (like the event store manager), of all the others, only a small fraction are needed per request. Instantiating them all + their dependencies with each request will just build a useless object graph that will consume time and memory. I don't see the above as an advanced use case. ZF (and Symfony 2) is promoting integration with Doctrine 2, so you are in a way pushing framework users to learn some patterns and good practices in order to get out of the PHP dark ages. And some of them are already trying to apply DDD and even CQRS using the currently available tools. Events are at the core of these two approaches, and having a capable EventManager is essential. -- View this message in context: http://zend-framework-community.634137.n4.nabble.com/ZF2-Di-EventManager-tp4485022p4489209.html Sent from the Zend Framework mailing list archive at Nabble.com. -- List: [email protected] Info: http://framework.zend.com/archives Unsubscribe: [email protected]
