-- ghola <alex.far...@gmail.com> wrote
(on Tuesday, 20 March 2012, 08:29 AM -0700):
> 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 this case, I typically crate module-specific listeners that register
such listeners. A good example is here:

    http://akrabat.com/zend-framework-2/module-specific-bootstrapping-in-zf2/

The idea is that when you know you have listeners with heavy
dependencies, you only attach them when they're needed. You do this when
specific routing criteria are made -- such as selection of a controller
in the current module namespace.

Does this answer your concerns?

> 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.

-- 
Matthew Weier O'Phinney
Project Lead            | matt...@zend.com
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

-- 
List: fw-general@lists.zend.com
Info: http://framework.zend.com/archives
Unsubscribe: fw-general-unsubscr...@lists.zend.com


Reply via email to