> Date: Tue, 20 Mar 2012 08:29:30 -0700
> From: alex.far...@gmail.com
> To: fw-general@lists.zend.com
> Subject: [fw-general] Re: ZF2 Di + EventManager
>
> 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: fw-general@lists.zend.com
> Info: http://framework.zend.com/archives
> Unsubscribe: fw-general-unsubscr...@lists.zend.com
>
>
I must say, I couldn't agree more.
zf1 for example, why
- load, parse, configure, etc... navigation
- load, configure, etc... view helpers (headTitle, headStyle, HeadScript, ...
the list goes on),
- load and configure database (load all db & db adapter files:classes, and
configuring it, etc.)
- etc... the list goes on...
Now serve a request for an rss feed.
Now serve a request for something that doesn't need the database.
Now serve a request for something that doesn't need the navigation.
etc... the list goes on...
Why load and configure these things when they are not needed? Why load them at
all?
The database config (let's say it's an array), when there is a request for
something that doesn't require it, *that config* should just stay an array, it
shouldn't be touched at all. The database classes:files should certainly never
be loaded, let alone configured.
I think this same problem exists in zf2 in various different ways, albeit more
complicated and thus hidden.
Load on demand should be priority. Load nothing, absolutely nothing, unless
absolutely neccessary. The overhead of a load on demand approach is far more
benificial than any alternative and is something that I think PHP frameworks
should strive for, not ignore, it's too easy to ignore, and I'm sorry, but I
don't think they do a good enough job. PHP is not java.
Regards,
Gerard
