Page 2 of 2

Re: Messaging between objects

Posted: Fri Jan 25, 2008 4:44 pm
by Christopher
Kieran Huggins wrote:In an MVC framework, couldn't you just attach the registry to the base controller class?
That's what is usually done -- either by passing it as a parameter to the constructor and/or methods, or by setting a property or calling a setter. That is one of the reasons why Front Controllers are so handy.

I prefer that a base controller class is not required because I find that most of the page requests in PHP apps are pretty trivial. Injecting a registry also means that the application can customize what is available based on need. So one of your applications may load up the Registry, whereas others just pass the basics like Config, Request and Response.

Re: Messaging between objects

Posted: Fri Jan 25, 2008 6:05 pm
by Weirdan
Kieran Huggins wrote:Closures limit the variable scope of a block, hence protecting your variables from naming conflicts.
This is what lexical scope provides. Closure, on the other hand, is what binds a function to the scope it was defined in (function's outer scope). Hence it's not limiting but, quite contrary, extending both the visibility and durability of a variable, because it provides the access to the variable from the block even if the block (function) is executed outside the context it was defined in.

Closures are used in javascript to emulate visibility controls natively provided by other languages:
[js] var MyObj = {};(function() {   var something = "asd";   MyObj.setSomething = function(value) {        something = value;   };   MyObj.getSomething = function() {        return something;   }})(); [/js]

which is a rough equivalent of the following:

Code: Select all

 
class MyClass {
    private $something = "asd";
    public function setSomething($value) {
       $this->something = $value;
    }
    public function getSomething() {
       return $this->something;
    }
}
 
Closure in the js code above is not that anonymous function, closure is the fact that inner functions can access the 'something' variable (and that the anonymous function is able to access 'MyObj' variable)

Re: Messaging between objects

Posted: Sat Jan 26, 2008 4:55 am
by Maugrim_The_Reaper
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.

Re: Messaging between objects

Posted: Sun Jan 27, 2008 9:53 pm
by Selkirk
One of the problems of injecting the registry object is that you gain a dependency on the registry/Service locator.

I think one consequence of this is that you end up with circular dependencies or sloppy dependencies. Since all the major objects in an app are basically always available through the registry, the dependencies in the whole app get tangled up and glued together through the registry. Not a critical issue, I think if you don't need to swap out components or reuse components of the app in other places and in other combinations.

I look at it this way. At the very lowest coding levels, you should always use DI to avoid dependencies. You should then try to use DI from the lower levels up, until you cannot do so comfortably. Then you switch to a registry or some similar solution.

Maybe it would be easier to use DI with controllers if the actions could more easily specify their requirements. Something like:

Code: Select all

function actionFoo(MyUserObject $user, DBConnection $db) { ... }