Controllers¶
Symfony follows the philosophy of "thin controllers and fat models". This means that controllers should hold just the thin layer of glue-code needed to coordinate the different parts of the application.
Your controller methods should just call to other services, trigger some events if needed and then return a response, but they should not contain any actual business logic. If they do, refactor it out of the controller and into a service.
Best Practice
Make your controller extend the AbstractController
base controller
provided by Symfony and use annotations to configure routing, caching and
security whenever possible.
Coupling the controllers to the underlying framework allows you to leverage all of its features and increases your productivity.
And since your controllers should be thin and contain nothing more than a few lines of glue-code, spending hours trying to decouple them from your framework doesn't benefit you in the long run. The amount of time wasted isn't worth the benefit.
In addition, using annotations for routing, caching and security simplifies configuration. You don't need to browse tens of files created with different formats (YAML, XML, PHP): all the configuration is just where you need it and it only uses one format.
Overall, this means you should aggressively decouple your business logic from the framework while, at the same time, aggressively coupling your controllers and routing to the framework in order to get the most out of it.
Controller Action Naming¶
Best Practice
Don't add the Action
suffix to the methods of the controller actions.
The first Symfony versions required that controller method names ended in
Action
(e.g. newAction()
, showAction()
). This suffix became optional
when annotations were introduced for controllers. In modern Symfony applications
this suffix is neither required nor recommended, so you can safely remove it.