arborint wrote:Yes ... the question becomes: at what level of complexity does the overhead of DI win out over the registry passing? There is no total answer usually. I find I use DI in areas of the application where the number of objects and complexity have exploded, yet keep using an injected registry for the rest.
That's the question I'm currently asking

. I've been going through controllers from an earlier application and keeping a tab on possible conditions for introducing a DI container:
a) once off objects not utilised in other typical controllers
b) objects with complex setup and decoration
c) objects incapable of creation prior to a controller dispatch
Broad sweeps, but I've been leaning towards reducing the reliance my controllers have on a Registry to common objects (i.e. stuff like sessions, configuration access, localisation) and leaning more towards one of DI or a lighter alternative (basically a minimalistic service locator). I've found this tends to reduce the complexity of my tests too - the minimalistic SL on once off controller objects especially since it requires a single setup line to substitute in a Mock Object.
Kieran Huggins wrote:In an MVC framework, couldn't you just attach the registry to the base controller class?
Depends what you mean by attach... Injecting via a setter or constructor is preferable with those methods located in the base class for controllers. Admittedly examples of that can be hard to find in PHP - I sometimes think PHP is too enamoured with singleton registries. As I noted to arborint, I've started to move towards keeping Registries restricted to very common very obvious objects so I'm less dependent on it as a general use storage vat for everything.