Symfony Controllers are the "glue code" that runs some logic and calls some services to serve each application route. They are a very stable piece of software that we rarely change. However, in Symfony 5.4 we've made some changes to controllers that may impact your applications.
Deprecated the Request::get() Method
The Symfony Request Object is an object-oriented representation of the HTTP request message. This object provides several methods to get information from the incoming request:
1 2 3 4 5 6 7 8
// retrieve information from $_GET
$request->query->get('id');
// retrieve information from $_POST
$request->request->get('category', 'default category');
// retrieve information from $_SERVER
$request->server->get('HTTP_HOST');
// retrieve information from $_COOKIE
$request->cookies->get('PHPSESSID');
In addition to these specific methods, there's a generic get()
method that
looks for information in path (routing placeholders or custom attributes), $_GET
,
and $_POST
and returns the first value found:
1 2
// this information could come from route attributes, from $_GET or form $_POST
$request->get('id');
The flexibility of this method could be useful in some edge-cases, but it's generally better to be explicit about where does data come from. That's why we've been discouraging the usage of this method from some years and in Symfony 5.4 we're marking it as private. You can still use it, but you'll see deprecation messages if you do, so it's better if you start upgrading your applications.
Deprecated Some Controller Shortcuts
In early Symfony versions, you could access all your application services from
the controllers using the get()
and has()
methods:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
// src/Controller/SomeController.php
namespace App\Controller;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;
class SomeController extends AbstractController
{
#[Route(...)]
public function someAction(): Response
{
$doctrine = $this->get('doctrine');
// ...
}
}
Later we removed this feature because accessing the entire service container in
this way is considered an anti-pattern. Therefore, the get()
method only allows
access to a very limited set of services related to controllers.
In Symfony 5.4 we're deprecating the get()
and has()
methods entirely.
Instead, fetching services in controllers should use constructor or method
injection. Besides, controllers provide a series of shortcuts for the most common
operations. For example, to redirect to some route, you don't need to inject
the UrlGeneratorInterface
class to get the URL generator service. You can
optionally use the redirectToRoute()
shortcut:
1 2 3 4 5 6 7
#[Route(...)]
public function someAction(): Response
{
// ...
return $this->redirectToRoute('...');
}
In addition to this change, we reviewed the list of shortcuts to see if we should add or remove some. We decided to deprecate the following controller shortcuts because they are not directly related to HTTP operations:
dispatchMessage()
getDoctrine()
Instead of using those shortcuts, inject the related services in the constructor or the controller methods.
Another great step for decoupling components. Well done!
Thanks
Moving on. :)
Just to clarify and help me to organize my code:
What about the implementation of the
ServiceSubscriberInterface
(e.g. on the\Symfony\Bundle\FrameworkBundle\Controller\AbstractController
)? The "smaller" container is not a recommanded way?For example, I like this approach when I have two public actions in my Controller that use the same one private method that requires a service. I don't want to inject the service in the two actions because it is the private method that depends on it directly (and I don't want to inject it in the constructor because I could have a 3rd action that doesn't depend on it).
In addition: shouldn't the
ServiceSubscriberInterface
/ServiceSubscriberTrait
be considered as a wa of "Injection Type"?(https://symfony.com/doc/current/service_container/injection_types.html)@Guillaume, you can still use $this->container->get() (as noted in https://github.com/symfony/symfony/pull/42442)
What about $this->json()?
Do I need to add Serializer to my controllers manually?
getDoctrine()
This change will ruin me mate :P
Can we still get Doctrine from the CI?? "$this->container->get()"??
Wowzer, the removal of getDoctrine() will mean a lot of controllers to fix.mean it entirely makes sense to decouple it... just a fair bit of work.
@Agamemnon, @Kris, you can make use of Rector (https://github.com/rectorphp/rector) to convert your controllers to use proper injection. No need to fear any extra work.
It seems that it is refactoring time. 100+ of $this->getDoctrine() to be replaced of one big app. It reminds me of the old getRequest() method.
I have been injecting
EntityManagerInterface
for quite a while now. Is that the correct way instead ofgetDoctrine()
?My colleagues tend to use
getDoctrine()
, mostly because it's in themake:crud
scaffolding a lot.I try to inject Repositories where I can, but if you must persist/flush/remove something I always inject the EntityManager...
In fact, this mean normally to change nothing, no need to extends this Abstract
@Joris Yes, that's the recommended alternative to using getDoctrine(). We're doing that change in the Symfony Demo too. See https://github.com/symfony/demo/pull/1268/files
@Joris you can always add a
public function save(Entity $entity)
function in your repository to do it. that's how i do stuff, even if it would break the doctrine's best practices. it makes sense to be there because only a repository should be between your service and the database.