Create Symfony apps as quickly as with Laravel, keep your code framework-agnostic

Slide 1

Slide 1 text

Symfony controllers, redesigned

Slide 2

Slide 2 text

Kévin Dunglas •Founder of Les-Tilleuls.coop •Symfony Core Team member •API Platform creator •Teacher at the University of Lille 1 @dunglas

Slide 3

Slide 3 text

Les-Tilleuls.coop •Self-managed company since 2011 •100% owned by employees •All benefits are equitably shared between employees •18 people, 137% growth in 2015 •We are hiring! => jobs@les-tilleuls.coop

Slide 4

Slide 4 text

What is a Controller?

Slide 5

Slide 5 text

By Martin Fowler http://www.martinfowler.com/eaaCatalog/modelViewController.html

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

The Symfony Book « A controller is a PHP function […] that reads information from the Symfony's Request object and creates and returns a Response object. »

Slide 8

Slide 8 text

github.com/dunglas/forumphp2016

Slide 9

Slide 9 text

This is Not a Controller

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

Rethinking Controllers… But Why?!

Slide 12

Slide 12 text

Controllers are Too Fat •Tend to put Domain / business 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…)

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

Controllers break OOP Best Practices •Magic and implicit •Container aware: no explicit dependencies •Hard to write SOLID controller classes •Hard to unit test controller classes •God objects (too much dependencies) Some people say « it’s OK for controllers »

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

Controllers are Coupled to SF It matters only for library developers: •Hard to reuse controller classes across projects •Cannot work with several frameworks •Cannot be distributed as standalone libs •Don’t support « standards » (PSR-7, PSR-15, PSR-17)

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

The ADR Pattern

Slide 19

Slide 19 text

The ADR pattern •Stand for Action-Domain-Responder •Web-specific refinement of MVC •A partial solution to previous problems https://github.com/pmjones/adr

Slide 20

Slide 20 text

The ADR pattern •Action: Connects Domain and Responder. Uses the 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.

Slide 21

Slide 21 text

Implementing ADR in a Symfony app

Slide 22

Slide 22 text

App’s Structure: Separating the Business Logic

Slide 23

Slide 23 text

Action

Slide 24

Slide 24 text

Action

Slide 25

Slide 25 text

Responder

Slide 26

Slide 26 text

Domain: Manager

Slide 27

Slide 27 text

Domain: Manager

Slide 28

Slide 28 text

Domain: Exception

Slide 29

Slide 29 text

Domain: Notifier

Slide 30

Slide 30 text

Services Registration

Slide 31

Slide 31 text

Routing Configuration (Invokable Controller as a Service)

Slide 32

Slide 32 text

Doctrine Configuration

Slide 33

Slide 33 text

Pros •Better design and structure (= easier maintenance and better 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)

Slide 34

Slide 34 text

Cons •Worst DX: lot of configuration files (YAML or XML) •Harder to refactor (RAD, prototyping…): require to update the config all the time •Mandatory Symfony skills: DIC configuration, controllers as a services, YAML/XML routing…

Slide 35

Slide 35 text

Autowired (Controllers as) Services

Slide 36

Slide 36 text

The DIC Autowiring Subsystem •Guesses, builds and injects automatically dependencies 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

Slide 37

Slide 37 text

Services Registration

Slide 38

Slide 38 text

Services Registration: Using Autowiring

Slide 39

Slide 39 text

A Better Developper eXperience •As easy as the the full 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)

Slide 40

Slide 40 text

Going Further with ActionBundle github.com/dunglas/DunglasActionBundle

Slide 41

Slide 41 text

The Action Bundle •« Replacement » for the whole Symfony 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)

Slide 42

Slide 42 text

Install composer require dunglas/action-bundle

Slide 43

Slide 43 text

Configuring Only necessary because action classes are not in a bundle.

Slide 44

Slide 44 text

Update the Routing Config…

Slide 45

Slide 45 text

… or use Annotations

Slide 46

Slide 46 text

No Service Registration Required!

Slide 47

Slide 47 text

The Action Bundle Included by default in API Platform 2 And maybe in a future Symfony version?

Slide 48

Slide 48 text

Bonus: PSR-7 and PSR-17 compatibility

Slide 49

Slide 49 text

PSR-7 and PSR-17 • PSR-7: HTTP Message Interface • PSR-17: HTTP Factories composer require symfony/psr-http-message-bridge zendframework/zend-diactoros http-interop/http-factory:dev-master http-interop/http-factory-diactoros:dev-master

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Update the Action

Slide 52

Slide 52 text

Update the Responder

Slide 53

Slide 53 text

Bonus: PSR-15 compatibility

Slide 54

Slide 54 text

PSR-15: HTTP Middlewares Schema by Slim framework

Slide 55

Slide 55 text

PSR-15 composer require http-interop/http-middleware:dev-master

Slide 56

Slide 56 text

Update the Action

Slide 57

Slide 57 text

Update the Action

Slide 58

Slide 58 text

Update the Responder

Slide 59

Slide 59 text

Update the Responder

Slide 60

Slide 60 text

Summary • Controller Autowiring and the Action Bundle improve the 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

Slide 61

Slide 61 text

Thanks! Any questions? https://joind.in/talk/6472b github.com/dunglas @dunglas