Maybe it’s just me, but when routinely maintaining around a million lines of code I damn well prefer straight forward solutions. I absolutely hate to do guesswork and hunt down 10 layers of unneccessary abstraction that makes absolutely no sense at all in a certain use case. To me these kind of solutions are a case of architectural austronautism. (See http://www.joelonsoftware.com/articles/fog0000000018.html )

Maybe it works if you have to maintain a lot of small sites, I don’t know. For me it’s way more trouble than it’s worth.

(And for the record: I don’t use Symfony, so I don’t have the luxury of having a plugin specifically written for the code I’m working on.)

Btw. how many times have you used a different DIC implementation in your life with a framework like Symfony?

$d = new DateTime('2012-03-23 14:00:00 CEST');
$d->format('m/d/Y'); // 03/23/2012

$d2 = clone $d;
$d2->modify('+3 day'); // 2012-03-26 14:00:00 CEST

$d->diff($d2)->format('%d days %h hours'); // 3 days 0 hours

$tz = new DateTimeZone('Europe/Budapest');
$tr = $tz->getTransitions(
          $d->getTimestamp(),
          $d2->getTimestamp());
$tr = array_slice($tr, 1);
if ($tr) {
    echo 'DST ' . ($tr[0]['isdst'] ? 'starts' : 'ends') .
        ' at ' . date('Y-m-d', $tr[0]['ts']);
}

The syntax is quite ugly at places, but it does the heavy lifting well.

/* MyModuleThatNeedsALogger.php */
class MyModuleThatNeedsALogger {
    /** @var iLogger */
    protected $logger;
    
    public function setLogger(iLogger $logger) {
        $this->logger = $logger;
    }

    public function doStuff() {
        $this->logger->flog('I did stuff!');
    }
}


/* MySecondModuleThatNeedsTheFirstModule.php */
class MySecondModuleThatNeedsTheFirstModule {
    /** @var MyModuleThatNeedsALogger*/
    protected $firstModule;

    public function setFirstModule(MyModuleThatNeedsALogger $firstModule) {
        $this->firstModule = $firstModule;
    }
}


/* services,xml */

When the first time you need the module, the DIC instantiates it and injects any dependencies. Inside your classes, you can just assume that all dependencies are magically there, and you can access them through typehinted fields; but, unlike the registry pattern, your classes do not depend on a god object, you do not need to create a mock registry for unit tests, you won’t pull all your hair out if you decide to switch to another DIC implementation etc.

/* @var $logger iLogger */
$logger = DIContainer::getInstance()->get(‘logger’);
$logger->log(‘my message’);