It's basically a matter of preference.
It is really a matter of practice. Experts will obviously know the
trade-offs of the options, but the point of focusing on a Best Practice
is to generally reduce problems. I would agree with Rob that other than
communicating with the other controller classes, using a Registry is a
better practice. And, if the community mostly uses a single practice
(especially with some conventions) then interoperability improves.
Do you need a global registry in
your application, or are you simply doing an MVC app?
This is a confusing statement. The choice to use a Registry has to do
with implementing some inversion of dependencies. That is a separate
issue from the decision on using MVC dependencies. And MVC can be used
for simple apps or very complex ones.
If your code isn't
going to be re-used in cronjobs, services, or other arenas, pushing the
database connection and config objects into the front controller (and
hence the router, dispatcher, and action controllers) might make as much
sense as using a registry, and save you the effort of loading and
calling on the registry within your code. If you *will* be re-using such
objects in other types of scripts, though, then passing them into the
registry probably makes more sense.
I'm not sure I understand the list of categories here. Any application
that needs consistent access to commonly used objects can benefit from
use of a Registry. I would recommend that ZF promote its use over FC
args. Its use is a discipline that can have far reaching benefits for
the ZF.
