symfony/symfony — pull request #11654 by remialvado (2014-08-12 09:00:31+00:00)
Title: [FrameworkBundle] Controller as a service

| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | none
| License | MIT
| Doc PR | none

Today, using controllers as a service is kind of a pain in the ass since the base Controller class (`Symfony\Bundle\FrameworkBundle\Controller\Controller`) is using services directly from the service container. When a controller is built as a service, the service container is not injected into the controller. This behavior of not injecting the whole service container into a service is a good thing : you don't want to depend on the whole service container. It would make your application quickly look like a spaghetti dish !
Nevertheless, in this case, since the service container is not injected, it will make the Controller class to fail on all of its functionnalities since `$this->get('anything')` will fail.

To avoid this, I've changed the way the Controller base class uses its dependencies : there are not retrieved from the service container at each usage but gathered once when the Controller is built and stores into public properties.
When the controller is used in the historical way (ie : not as a service), public properties are filled at Controller creation.
When the controller is used as a service (as it should be I think), public properties can be properly injected by the subclass (either using setter injection 'Symfony-style' or public properties injection 'JMSDiExtraBundle-style').

I've also marked `get` and `has` methods as deprecated since it is really a terrible idea to inject (and thus use) the service container inside a service. As of Symfony 3.0, it would be good I think to remove the `implements` on ContainerAware and to stop injecting the whole service container

I've also changed the dependency from `Doctrine\Bundle\DoctrineBundle\Registry` to `Symfony\Bridge\Doctrine\RegistryInterface` to avoid a soft dependency towards a non mandatory bundle (moreover, it is better to depend on the actual interface instead of one implementation).