9

I have started to go through Symfony2 code, studied a little bit small classes like Pimple and after few hours of examination have come to strange idea. The best start for this is to explain how I understand few terms, so:

Dependency Something which is needed for another thing to work, like "engine" in "car"

Container Object or class which is able to store a lot of another objects, like "engine","gearbox" or even "car"

Dependency Injection Process in which every dependency is injected to object, so if I need "car" I know that I have to inject "engine","gearbox" and a lot of another stuff. Important is, that "car" don't create "engine", but "engine" is put inside "car"

Service Locator Process in which object asks for another object, for example into the car there is inserted our container, and when car need to start it require from container "engine", so container return him "engine"

When i studied Symphony code, they start with dependency injection, but after some time I realize that when Controller is created, there is injected whole container and then you can use $this->get('serviceName') to get it, so it more looks like service locator, which according to few articles is anti-pattern.

Sow how is it? Is that line between DI and SL so small that it is sometimes broken? Or did I misunderstood something? If I use DI, do I need to insert every service into controller, so I know from outside what I use? Or can controller become in some cases container?

Improve this question

1 Answer 1

Reset to default
10

Your understanding of DI is pretty good. And yes, Symfony Controller does implement ContainerAwareInterface, and as you said, has a service locator role. But service locator isn't an anti-pattern. Each pattern has it's proper and improper uses.

Furthermore, Symfony doesn't enforce you in any way to use it's Controller. Your Controller can be a service. Hell, it can even be a function!

Here is one of the reasons why Controllers are implemented as service locators: Performance.

Let's drop car analogy and focus on real case that you'll encounter in 99% of projects: you need CRUD for a resource. Let's say you're building a Todo app and you need a RESTfulish controller to handle CRUD operations for Task Resource.

The least you need to have is a way to read all tasks and a way to add a new task, for that you need two actions: index (commonly named list too), and store (commonly named create too).

Common flow in Symfony would be this, in pseudo code:

indexAction -> getDoctrine -> getTaskRepository -> getAllTasks storeAction -> getFormFactory -> createForm -> bindRequestDataToForm -> getDoctrine -> saveData

If Controller was a service locator

Index Action

When index action is executed, only service that will be resolved from the container will be ManagerRegistry (in this case Doctrine service). We will then ask it to give us task repository, and we'll do our operation with it.

Store Action

When store action is executed, we will do a bit more work: ask container to give us FormFactory, do some operations with it, and then ask it to give us Doctrine and do some operations with it too.

So summary: when index action is executed, only one service has to be constructed by service container, when update is executed, two will have to be constructed.

If Controller was a regular service

Let's see what our Controller needs. From the section above, we see that it needs FormFactory and Doctrine.

Now, when you just want to call index action to read all tasks from data storage, your controller will have to get instantiated by container. Before it can be instantiated, container needs to instantiate it's dependencies: FormFactory and Doctrine. Then instantiate controller while injecting those two into it.

So, you are calling index action which doesn't need FormFactory at all, but you still have overhead of creating it because it is needed for an action that will not be called at all in that request.

Lazy Services

To reduce this overhead, there is a thing called lazy service. It works by actually injecting a Proxy of your service into the controller. So, as far as controller is concerned, it got FormFactory. What it doesn't know is that isn't real FormFactory but instead a fake object which will delegate calls to real FormFactory code when you call some method on it.

Wrapping it up

Controller doesn't have to be a service locator, but can be. Making it a service locator can be a bit more performant and easier to bootstrap, but hides dependencies. Furthermore, it's a bit harder to test, since you'll need to mock dependency container. Whether you want to make your controllers services, functions or service locators is your choice and Symfony won't enforce you to use any of those ways.

In my experience, extending default Symfony Controller and having controllers be service locators is just fine as long as you don't write your business logic in them, but instead delegate all that work to services, which you get from container. That way, it's really unlikely that you'll have bugs in controller code (as methods will usually consist of 2-3 lines of code) and can get away without testing it.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Good question. Good answer. You can eliminate the unnecessary services by limiting yourself to one action per controller. I like to use a hybrid approach in which I inject my services into the controller's constructor while still injecting the container via setContainer to make use of the methods in the base controller class. 2-3 lines of code does seem a bit optimistic even for a thin controller action.
It's worth noting that breaking up the controller into smaller subset of similar actions or dedicated a class for every action would also avoid instantiation of unnecessary dependencies while also providing a better adherence to the SRP.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.