Re: the ImageTransformer example — most DI tools wouldn’t instantiate an object unless it was actually required as a transitive dependency, so this seems like a moot point. I think the real performance issue would be loading the DI config; i.e. how do you actually build an object of class XYZ.

All this said, I applaud Solar for including at least rudimentary DI support. I haven’t seen much of this in PHP frameworks, and it’s a shame that few of them consider testability a worthy goal.

I still don’t see how a true DI solution would work in PHP, though (as I mention on Jeff’s blog). To really wire everything up would add an unnacceptable level of overhead to my PHP scripts — e.g. my framework may require that certain objects get wired with a desired ImageTransformer driver, but 90% of my page requests don’t need an ImageTransformer at all.

This appears to me to be a problem that is inherent in trying to invert control for an environment like PHP. Because PHP environments must (generally) be recreated for every request, there is a good reason to keep control of the object setup on-demand within the service classes themselves — i.e. with PHP there is a good reason not to invert control.

… Now, I suppose that this wouldn’t be the case if the IoC layer could somehow magically wire-on-demand. But any implementation I can think for that just starts to look like a service locator.

-H

Perhaps it is a Service Locator after all; Fowler notes they are very similar, which would explain my selection of the wrong term.

http://www.martinfowler.com/articles/injection.html#DecidingWhichOptionToUse

Solar_User::__construct(Solar_Auth $auth, Solar_Role, $role, Solar_Access $access);

With that, you would request a User object (i.e., $dependencyManager::object(‘Solar_User’)) and the manager would take care of locating the dependencies, not the User object. The idea is that the object, other than offerring what it needs, has no clue on how to go about getting them. As soon as you add in the code within Solar_User, it moves from true DI to another very similiar pattern in outcome. Service Locator sounds right, but I’m not sure.

Of course, for true DI, you would have to either re-think your implementation of Solar (i.e., no single $config parameter) or have some way to define what’s expected by an object (i.e., Solar_User::expectedParameters() : array()).

Here’s an example from the User object (see the __construct() method) –

http://solarphp.com/svn/trunk/Solar/User.php

The internal auth, access, and role objects are set up via the configuration params; as long as the passed objects (or object parameters) are descended from the proper class, the dependency is accepted for internal use.

If you send a Mock_Solar_Auth object descended from Solar_Auth, it’ll work without changes to the User class. If you send a string that represents a Mock_Solar_Auth object in the registry, that’ll work too. Finally, if you decide to use a Solar_Auth_Adapter_Mock adapter in the facade Solar_Auth class, but want the User object to instantiate that object internally, that will work as well.

With respect to storing objects in the registry via dependency injection: no, you register an actual created object and give it an identifying key string. Registry objects can lazy-load themselves, though, if you pass a class name and configuration array instead of an object; this will cause the object to be instantiated on first request from the registry.

I hope this begins to answer your question; please let me know if it does not.

Maybe an example would make this clear: Say I’m using the Solar framework and I want to swap out all my “real” drivers for “mock” versions (e.g. my SMTPMailSender gets swapped out for MockMailSender). What file(s) would I need to change to make this happen?

-H