-- Benjamin Eberlei <kont...@beberlei.de> wrote (on Tuesday, 13 January 2009, 06:11 PM +0100): > 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.
It would be the job of the constructor to ensure that required options are passed, then -- or to provide defaults (potentially through an overloaded accessor that lazyloads a default). > 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. However, this adds another dependency to using the objects -- you then need a value object before you can even use the object. If we allow either an array or a Zend_Config object, we give more flexibility in userland code for how the options are retrieved and passed to the constructors (they could be subtrees of an application-wide configuration object, or a serialized JSON array stored in memcached, etc). > 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. If you look closely at Ralph's example, you'll notice it wasn't static. :) He and I have discussed this a fair bit, and the idea is that factories and other "gateway" classes would push themselves and/or the registry down into the subcomponent objects. > 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. I've been pushing the setOptions/setConfig paradigm for a while, and it works really well with DI. Your constructor then passes the options on to setOptions() which attempts to call setters named after the keys. The result is that it allows you to push your dependencies in at instantiation -- leaving the constructor needing to simply check for required settings (if any) only. > 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 > -- Matthew Weier O'Phinney Software Architect | matt...@zend.com Zend Framework | http://framework.zend.com/
