Symfony2: Moving Away From the Base Controller

When you start learning Symfony2 using the book, you are introduced to the base controller. The base controller has some helpful methods to make common tasks easier. After a while though you may want to move away from extending this controller, in fact, it is the advised best practice for controllers in shared bundles. When you do, you will no longer have access to these useful methods, in this post I am going to look at how to accomplish the same tasks without them.

I have created a simple controller for some basic form interaction with a model which uses the base controllers methods. I am going to go through how to change this to a service which does not extend the base controller. The starting point looks like this:

It uses a form type object LimeThinkingSpringBundleFormTestimonialType for the form which looks like this:

The controller as it stands has actions for displaying, adding and editing testimonials. I have extracted the common tasks, retrieving a testimonial from the database and rendering the form, into their own methods. It is routed to like this:

Removing Helper Methods

To start with I am going to change the helper methods to use services still retrieved using the get() helper method which is a short cut for getting services from the container. After this is complete we can convert to a service and inject the required services instead.

The methods we need to replace are:

  • getDoctrine()
  • generateUrl()
  • render()
  • createForm()
  • redirect()
  • createNotFoundException()
  • get()

Once all these are gone we can stop extending SymfonyBundleFrameworkBundleControllerController. To start we will actually introduce more use of get() as this allows us to access services from the Dependency Injection Container (aka Service Container).


The easiest to remove is getDoctrine():



Next up generateUrl():







Now for a couple that are slightly different:


We also need to add:

to the use statements at the top of the file.




added to the use statements.


is just a shortcut for

So we can replace all the get() calls throughout.

Now that all the methods from the base controller have been removed we can change to extending ContainerAware instead. doing so means that the container is available to the controller. So the class now looks like this:

Defining the Controller as a Service

We can also now move to defining our controller as a service. See this cookbook recipe and my post Symfony2: Controller as Service for details on how to do this and how to set up an Dependency Injection extension to load a service definition for a bundle. In this case we would change to routing to the controller like this:

with a services XML config like this:

Note that the container is explicitly injected into the service using the method defined in ContainerAware as this is no longer automatically done.

Injecting Services

Now for the more controversial bit. In my opinion injecting the container in this way is not the correct way to use it. I have written about this in these posts: When Dependency Injection goes Wrong and In Defence of Dependency Injection Containers. This is not the opinion of everyone and not an official best practice, it is just my recommendation.

I have also looked at how to inject dependencies in Symfony2 in these posts: Symfony2: Dependency Injection Types and Symfony2: Injecting Dependencies Step by Step. So I am not going to go over how to do this in detail again this time, the end result of removing the services is that the class looks like this:

and the services XML like this:

Edit: As per Stof’s comment the predefined request service should be used. As this is scoped to request the controller will also need to be scoped to request to avoid scope widening. The services.xml should then look like this:

There are still some objects being created using the new keyword. These are all effectively value objects though rather than services. That is to say that they hold specific values and would not be reusable in other classes in the same way that the other injected services are. The RedirectResponse, for example, is specific to the testimonial not being found and is not something we could inject using the container. There is an argument that this is still a dependency that should be removed. If you are that way inclined then a way to do it would be to instead inject Factory objects to create these objects on demand. The factory could then be mocked for testing or a different factory used if you wanted to change the object returned. If you do want to do this then at the moment you will have to write your own though.