Black Friday 2021 Offers 30% discount on Certification, Coaching, and SymfonyInsight Teams subscriptions

New in Symfony 5.4: Controller Changes

Symfony 5.4 is backed by Private Packagist. Private Packagist is a fast, reliable, and secure Composer repository for your private packages. It mirrors all your open-source dependencies for better availability and monitors them for security vulnerabilities.

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

Contributed by
Roland Franssen
in #42392.

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

Contributed by
Fabien Potencier
in #42422 and #42442.

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.

Help the Symfony project!

As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.

Comments

Another great step for decoupling components. Well done!
Thanks
Moving on. :)
Just to clarify and help me to organize my code:

> [...] fetching services in controllers should use constructor or method injection.

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 of `getDoctrine()` ?

My colleagues tend to use `getDoctrine()`, mostly because it's in the `make: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.
Login with SymfonyConnect to post a comment