|
4 | 4 | How to Define Controllers as Services |
5 | 5 | ===================================== |
6 | 6 |
|
| 7 | +.. caution:: |
| 8 | + |
| 9 | + Defining controllers as services is **not officially recommended** by Symfony. |
| 10 | + They are used by some developers for very specific use cases, such as |
| 11 | + DDD (*domain-driven design*) and Hexagonal Architecture applications. |
| 12 | + |
7 | 13 | In the book, you've learned how easily a controller can be used when it |
8 | 14 | extends the base |
9 | 15 | :class:`Symfony\\Bundle\\FrameworkBundle\\Controller\\Controller` class. While |
10 | | -this works fine, controllers can also be specified as services. |
11 | | - |
12 | | -.. note:: |
13 | | - |
14 | | - Specifying a controller as a service takes a bit more work. The |
15 | | - primary advantage is that the entire controller or any services passed to |
16 | | - the controller can be modified via the service container configuration. |
17 | | - This is especially useful when developing an open-source bundle or any |
18 | | - bundle that will be used in different projects. |
19 | | - |
20 | | - A second advantage is that your controllers are more "sandboxed". By |
21 | | - looking at the constructor arguments, it's easy to see what types of things |
22 | | - this controller may or may not do. And because each dependency needs |
23 | | - to be injected manually, it's more obvious (i.e. if you have many constructor |
24 | | - arguments) when your controller is becoming too big. The recommendation from |
25 | | - the :doc:`best practices </best_practices/controllers>` is also valid for |
26 | | - controllers defined as services: Avoid putting your business logic into the |
27 | | - controllers. Instead, inject services that do the bulk of the work. |
28 | | - |
29 | | - So, even if you don't specify your controllers as services, you'll likely |
30 | | - see this done in some open-source Symfony bundles. It's also important |
31 | | - to understand the pros and cons of both approaches. |
| 16 | +this works fine, controllers can also be specified as services. Even if you don't |
| 17 | +specify your controllers as services, you might see them being used in some |
| 18 | +open-source Symfony bundles, so it may be useful to understand both approaches. |
| 19 | + |
| 20 | +These are the main **advantages** of defining controllers as services: |
| 21 | + |
| 22 | +* The entire controller and any service passed to it can be modified via the |
| 23 | + service container configuration. This is useful when developing reusable bundles; |
| 24 | +* Your controllers are more "sandboxed". By looking at the constructor arguments, |
| 25 | + it's easy to see what types of things this controller may or may not do; |
| 26 | +* Since dependencies must be injected manually, it's more obvious when your |
| 27 | + controller is becoming too big (i.e. if you have many constructor arguments). |
| 28 | + |
| 29 | +These are the main **drawbacks** of defining controllers as services: |
| 30 | + |
| 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; |
| 33 | +* 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. |
| 37 | + |
| 38 | +The recommendation from the :doc:`best practices </best_practices/controllers>` |
| 39 | +is also valid for controllers defined as services: avoid putting your business |
| 40 | +logic into the controllers. Instead, inject services that do the bulk of the work. |
32 | 41 |
|
33 | 42 | Defining the Controller as a Service |
34 | 43 | ------------------------------------ |
|
0 commit comments