logic in the controller (bad practice) Creating services requires some Symfony skills •Methods with too much lines of code (#previousLine) •Bloated controller classes with a lot of methods •Duplicated code (e.g. to generate a Response with HTTP headers, to call the view…)
request input to interact with the Domain, passes the Domain output to the responder. •Domain: The app’s business logic. Modifies states, persistence. Manipulates session and env data. •Responder: Build an HTTP response. Body content, templates, views, cookies, status code and so on.
adaptability) •Easier to unit test (including actions and responders, thanks to explicit dependencies) •All chunks of code are independently reusables •No more duplicated code (e.g. headers) •Agnostic of the (full stack) framework: classes depend only of components (standalone libs)
of a service using PHP’s reflection API •If a service of the given type exists: it is injected •If it doesn’t exist: it is created then injected •Allows to map an interface to a default implementation •SF 2.8+, will support method injection in 3.2 •No performance impact at runtime
stack framework’s base controller •No need for magic proxy methods (getDoctrine(), json()…) •Easier refactoring: create new classes, add new dependencies, they are automatically built and injected with 0 config (Laravel-like)
controller layer: actions, commands, event subscribers •Action classes, commands and subscribers are automatically registered as services •Autowiring is on for all those services •Configurable (scanned directories, interfaces, tags…) •250 lines of code for 180 GitHub stars (best ratio ever)
DX and ease the refactoring • ADR gives more structure to your app and is better from a design point of view • If you are a library developper, you can create standalone, framework agnostic actions working with Symfony and using PSR-7-15-17