Skip to content

Dependency Injection Containers

I got into a discussion on Twitter the other day where I mentioned that I don't like DI. Call it lack of sleep or language barrier (on my part), but I said DI — dependency injection — when I meant the dependency injection container. Having said this, let me explain why I don't like it.


Despite not working for any of the larger PHP joints out there, I get to spend my time with pretty interesting stuff. I wouldn't call it high traffic or big data, but being in the Top 100 websites, we're certainly not the average PHP application out there.

I've shared some numbers perviously, and also in our job posting — don't mean to compare size, but my perspective is just that.

Looking at anything, I'm compelled to ask myself:

  • How much time will it save during development?
  • How much time will take to educate my team?
  • How much time will it eat away in each request?
  • How much time will it cost me to rip it out when it's slow?

Yeah, I'm still crazy about technology, but I've also grown up to not just submit to any of it without thorough evaluation. In that respect, I've grown old(er) — but that's (IMHO) healthy sceptism and usually what people call experience.


At the expense of my own credibility, let me just say (again) that I'm not particulary against new things. My beef is the hype.

The fact is that we use a lot of new technology and I have to admit that it's pretty exciting for me when to try out new things. Trying out doesn't mean that we end up using it, but when we try out we take a close look.

On the newer side of things we ended up using CouchDB, Redis, Membase and ElasticSearch. On one or two of these we have even started hacking and all in all we follow their development closely.

Telling people about what we run, sometimes feels like I run a playground for developers and crazy-about-tech people. It's new and it's bleeding edge, and it may be true to a certain extend, but it also the opposite because we (believe we) found great use-cases for each of these things.

But getting back to patterns, and I believe these prove my point even better than going on about these databases: Be honest to yourself and let's define "new" in this case and in general. Because neither dependency injection nor containers, or NoSQL are exactly new.

I don't want to rain on anyone's parade, but get real — it's been said and done before.

A little pain^H^H^H^H^Java never hurt anybody

While I personally agree with some of what Luke Welling wrote in his article "PHP is not Java" for PHP Advent 2008, I also disagree with the general tone of the article and the examples he provides. The example Luke provides might be true in some respects (that it looks like Java code), but the solution offered is the best example why PHP and PHP developers are looked down on most time.

PHP is the red-headed step child (no offense to redheads, I love you all) when it comes to programming, or wait, scripting languages. Because PHP is not even a programming language. ;-) For example, when I started at this co-working place most of the people did not talk to me at all. Besides Jan, who I share the room with most of the time, there are only Ruby (and Java) people on this floor. Horror, right? (Just kidding!)

And even though my crap PHP code handles much more traffic than their fancy rails, and even though I'm open to other languages as well, most people stop taking me serious when I admit to doing PHP.

The truth is out there, Mulder.

The notion of the last years has been that a lot of PHP-based open source projects worked hard to improve the quality of their code by defining coding standards, by improving the documentation and sometimes even by adding a dedicated QA team. Even though any PR is good PR, no one wants to make those headlines. The (by no means complete) list of examples include (of course) PEAR, Joomla (where this is an ongoing effort :-)), and also rather notorious projects such as phpBB and Wordpress.