Comments inline: > The better solution is dependency injection, and one facet of this is removing
I disagree (if you are talking about DI as a container model) > explicit references to Registry/global items from source code. This is a I agree. > feature the ZF has yet to include but Bradley Holt has ressurected the idea in > the form of Zend_Container ( > http://framework.zend.com/wiki/display/ZFPROP/Zend_Container+-+Bradley+Holt ) > and I really really hope it, or an evolution of it (Zend_Application plugin?), I agree > makes it into the library. The last time something like this was proposed it > was bogged down by ever expanding requirements and complexity - True, as DI Containers tend to get. > simpler is better. +1000 here :) .. Now onto the explanation. To sum it up, I do think we need a solution here that will fit the framework, specifically our components- framework wide, as well as application wide. But, DI Containers (to me) have always introduced a level of indirection that is extremely uncommon for PHP. There are two ideas, I would love to see explored, and both of them would be rooted in what I would call a "component development convention", but only at the most forward facing API layer. First, the __construct($options = array()) {} convention for the most forward facing component API constructor adds a level of consistency that makes each and every component look and feel similar in style. This would makes it easy to move from component to component and have a good understanding of what is expected. Zend_Form does this, and to me, it make for the most flexible of components. In each case, $options can be a Zend_Config object, and assoc array of configuration values which can then be pushed down into the varios setXXX() methods, or $options can be the single most well used value, (if this were a Zend_Service component, it could be the API key). I believe this convention is very much used in Solar and its becoming more popular in ZF as we see more components hit the library. Second, I propose we look at creating a Registry class that can be extended (maybe its just a glorified ArrayObject), that can be used and defined by each component. This would allow components to have a *Component Level Registry*. How would this help? Well, instead of there being a dbAdapter key in the Application space registry, Zend_Db_Registry would contain a getDefaultAdapter() method. It might also have a getAdapter($name) method. Also, now the Zend_Db component can manage is component level registry and made the best decisions on how to lazyload and expose its individual pieces to the application layer, or user layer. For Zend_Controller, the api might look like this: Class Zend_Controller_Registry { public function getFront(); public function getDispatcher(); public function getRouter(); public function getRequest(); public function getResponse(); /* .. Others .. */ } Again, this delegate the responsibility down into the actual component of wiring dependencies, and either throwing an exception or lazy-loading when a non-explictily-set wiring is needed. This also alleviates the need for a god-like container to find, or be given a wiring diagram (which could become expensive for instantiation of every PHP object needed) to be able to work within all components and between all components. ALSO (if this is more of a convention Zend_Controller_Registry extends ArrayObject), this would reduce the intra-component dependencies. Also, PHP is not java, so containers need to be rebuilt on each request, whereas in Java the container might need to be built once and put into resident memory for all requests. Those are two ideas I wanted to float ever since hearing of DI. Im sure this will turn in to a blog post, since its more of a how does DI affect PHP sort of question. Let me know what you think. -ralph -- Ralph Schindler Software Engineer | [email protected] Zend Framework | http://framework.zend.com/
