My first stab at the Dependency Injection Container in Zend Framework 2

So, let me explain… no, there is too much.  Let me sum up.

With beta 3 now being released I have started to spend some time getting used to the new MVC components and the architecture in general.  I turns out that was too much.  When I learn something new I like to start with something broken and fix it.  This forces me to understand how things work a little better.  But I ran into a problem that MVC is so dependent on other concepts in ZF2 that until I understood those concepts I would be spinning my tires trying to get an MVC-based application running without much benefit.

So since I already know how to use event managers the next most basic thing I needed to understand was Dependency Injection.

It turned out that I was actually using Dependency Injection and just didn’t know it.  You know all of those iterative addElement() calls in Zend_Form?  Dependency Injection.  Getters and Setters like setPluginLoader() or setTranslator()?  Kinda the same thing.  Basically, if you don’t call the constructor inside of an object you are likely going to be injecting functionality into that object.  Whallah!  Dependency Injection.  While that does not encompass DI, it is a good starting point.

But one of the problems with manually injecting dependencies is just that; it is manual.  Need a view object?  Create and inject it.  Need to use it 20 times?  Create it once and inject it into any object that needs it, making sure to pass it around to any component that may need it.  It’s a bit of a hassle.

Enter the Dependency Injection Container.  What this allows you to do is write a class and maintain an instance of that class in a container so rather than making sure you have injected every dependency you just inject the container.  There’s more to it, such as creating definitions, but that’s all you need to know for a starting point.

Setting up DI is actually really easy.  Let’s start with a class.

1
2
3

class Test
{
}

Now let’s create our DI container

1

$di = new Zend\Di\Di();

Now let’s get an object

1

$test = $di->get('Test');

There you have it.  You are now using a Dependency Injection Container.  Instead of passing that Test object around to everything that needs it simply pass the container and you can get it, or any other object in the container, in one place.

So what if your object actually needs some data injected into it?  Add a constructor!

1
2
3
4
5
6
7
8
9

class Test
{
  protected $test;
 
  public function __construct($test)
  {
    $this->test = $test;
  }
}

Now to get an instance with data passed in the constructor we need to add the constructor parameters to the DI call.

1

$test = $di->get('Test', array('test' => 'value'));

If we do a var_dump() on $test we will now see that the protected variable $test has the value “value” attached to it.

The last thing we will look at is calling a setter.  Setters can have a little more complexity to them but the basic usage is very much the same.

Let’s start with our class.

1
2
3
4
5
6
7
8
9

class Test
{
  protected $test;
 
  public function setTest($test)
  {
    $this->test = $test;
  }
}

Now we call our DI container

1

$test = $di->get('Test', array('test' => 'value'));

And we get the object with the setter called.  Notice something?  We didn’t change the code to call the DI container.  What happened was because the container constructor was removed the DI container tried to find a proper setter for the key “test”.  That was called setTest() and so it called the setter and the value was injected.  So what happens when we have both a constructor and a setter?  With this code they are both called twice.

With that you can see some very basic usage of a dependency injection container.  While any application of any size will have more complexity to it these examples show that to get up and running with DI and a container are actually not very complex.  But while this is simple I will be going into much more depth in subsequent blog posts to expose some of the power that comes with using a DIC.