great post ralph! this is a step into a brighter future ;-D my two cents though.
1. having __construct(array $options); is cool from a simplicity point but it hides dependencies, since in an array you couldinclude ANYTHING. Most components also don't require the dependencies to be set in constructor, they take all sort of options and set them but don't raise an exception when a depdenency xyz misses. When you have a sensible default depdenency this would make sense though. ezcComponents uses constructor struct objects for configuration. You would have an object Zend_Controller_Config which enforces some variables and is given to the constructor. I like this alot, since objects always allow for more checks on variables than arrays. 2. component registries are a great thing IF they are not singletonized. They allow for type checking and consistency checks where the Zend_Registry does not. You could always make a container go into Zend_Registry to make it global, but this should be optional, and pleeease let us just forget the singleton antipattern. :-) If component registries are used we should make sure that all dependencies are overwritable with them, for example the PluginLoader of Zend_Controller for helpers is hardcoded into the front controller. The component registry should include all objects that might impliciltly be set deep in the object graph of the component. That would be super! 3. Implicit dependencies and work in the Constructor Dependency Injection is also about not having implicit dependencies or much work in the constructor. We should evaluate all components based on this. Having a "new Something()" inside an object constructor is evil, aswell as doing lots of stuff that you cannot influence. greetings, Benjamin On Tuesday 13 January 2009 16:55:57 Ralph Schindler wrote: > 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+Ho > >lt ) 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 -- Benjamin Eberlei http://www.beberlei.de
