@@ -23,17 +23,19 @@ These are the main **advantages** of defining controllers as services:
23
23
service container configuration. This is useful when developing reusable bundles;
24
24
* Your controllers are more "sandboxed". By looking at the constructor arguments,
25
25
it's easy to see what types of things this controller may or may not do;
26
+ * If you're not passing some required dependencies or if you are injecting some
27
+ non-existent services, you'll get errors during the container compilation
28
+ instead of during runtime execution;
26
29
* Since dependencies must be injected manually, it's more obvious when your
27
30
controller is becoming too big (i.e. if you have many constructor arguments).
28
31
29
32
These are the main **drawbacks ** of defining controllers as services:
30
33
31
- * It takes more work to create the controllers because they don't have
32
- automatic access to the services or to the base controller shortcuts;
34
+ * It takes more work to create the controllers and they become more verbose
35
+ because they don't have automatic access to the services and the base
36
+ controller shortcuts;
33
37
* The constructor of the controllers can rapidly become too complex because you
34
- must inject every single dependency needed by them;
35
- * The code of the controllers is more verbose because you can't use the shortcuts
36
- of the base controller and you must replace them with some lines of code.
38
+ must inject every single dependency needed by them.
37
39
38
40
The recommendation from the :doc: `best practices </best_practices/controllers >`
39
41
is also valid for controllers defined as services: avoid putting your business
0 commit comments