Symfony2: Injecting Dependencies Step by Step

In this post I will go through removing directly created dependencies from a Symfony2 controller and instead injecting them using The Dependency Injection Container (DIC).

At the end of my last post I had an Asset Controller which looked like this:

In the post I am going to go through the steps I went through to change it to this:

The second is much cleaner, much of the leg work of setting up the Asset and Filter managers has been removed. Also all the direct instantiation of objects has been removed, this means that testing will be much easier. So where has the missing code gone? It has been replaced by using the Symfony2 Dependency Injection Container to do the work for us. I am going to go through the steps I took to start removing the dependencies.

Note: this asset controller is not actually necessary as Assetic can be configured directly from Twig, see Kris Wallsmith’s comment on my previous post. My follow up post Symfony2: Using Assetic from Twig has more on this. However what it actually does is not relevant to the content of this post, it is more an exercise in how to inject dependencies.

To start with the controller needs to be called as a service and an XML config file created for the bundle. Please read my post Symfony2: Controller as Service for more details. We can start with the low hanging fruit, the controller’s dependencies that have no dependencies themselves. Instead of creating these in the controller they can be passed in via constructor injection. The controller now looks like this:

and the XML config file like this:

Each of the dependencies we are passing in is defined as a service and the id associated with used to pass them as constructor arguments to the controller service. Also of note is that you can parametrise the settings themselves, I have pulled out the name of the class being used for formula loading in order to make this easier to change.

For the next step we can remove the dependencies which have their own simple constructor parameters.

One new introduction here is the use of some of the global parameters: kernel.rootdir and kernel.cachedir within the parameters. These are fairly self explanatory and are an excellent way to avoid having absolute paths in the service configuration. A list of the available global parameters appears in this page of the Symfony2 documentation.

We’re starting to get there now, unfortunately our constructor argument list is growing, fortunately the next step will help with this. Quite a few of the remaining lines of code are calling setter methods on the dependencies, usually with another of our dependencies being passed in. We can use the Symfony2 Dependency Injection Container’s support for Setter Injection to deal with these. The controller can now be changed to this:

The XML file now instructs the DIC to call the methods and which service to pass to them. The YUI Compressor is passed to the filter manager, which is in turn, along with the asset manager, passed to the asset factory. This means that the compressor, filter manager and asset manager can all be removed from the PHP code altogether as the asset factory is injected already set up with them. In a similar way we can now go further and just pass in the AsseticController set up with its dependencies already and eliminate these from the code in the final step.

The LazyAssetManager is passed to the AsseticController by the DIC but as we need to set the formula it still needs to be injected in to the controller as well. It is the same service that is injected into each so this presents to problems, by setting the formula in the LazyAssetManager passed in it is available in the AsseticController.

The code is now cleaner and whilst we have a fairly hefty config file it is now easy to change the configuration by just editing this file. For example to make additional filters available in the filter manager I do not need to touch the PHP code at all, to also make a JavaScript YUICompressor available the config needs changing to this:

Hopefully this post helps with showing you Dependency Injection can be used to clean up code by separating the configuration or “wiring” of the object tree from the execution, as well as how to do this with the Symfony2 Dependency Injection Container.