The View Model pattern with Symfony2

1. LE PATTERN VIEW MODEL AVEC
SYMFONY2

2. QUI SUIS-JE ?
Romain Kuzniak
@TurnItUpMethod
Responsable Technique chez OpenClassrooms
1 M de membres, 2,7 M de VU / 25-30 M de pages vues
Design applicatif, musique et Symfony2
Designs applicatifs avec Symfony2

3. DE QUOI EST-IL QUESTION ?

4. ViewControllerDomain

5. ViewControllerModel
MVC

6. Presentation
Layered
ViewController
Business
Layer
Data
Layer

7. Presentation
Infrastructure
Domain Driven Design
Domain
Layer
Application
Layer
ViewController

8. Presentation
ViewController
Entity
Clean Architecture
Use Case
Gateway
Implementations
Boundary

9. Presentation
Vue Controller
Data
WTF Design
Kitten
Layer
Unicorns
Park

10. CONTROLLER

11. VIEW

12. SIMPLE, MAIS …
Le post suivant
La liste des derniers posts vus
La liste des posts les + vus
Une recommandation de posts
…

13. QUELS SONT LES PROBLÈMES ?

14. APTITUDE AU CHANGEMENT
La présentation dépend du domaine
Un changement entraîne des changements dans
toutes les couches
Too much knowledge

15. LOGIQUE DANS LA VUE
Pour gérer des cas métiers
Pour gérer des variables non-définies
Pour gérer des valeurs par défaut

16. LOGIQUE DANS LA VUE
Pour gérer des cas métiers
Pour gérer des variables définies
Pour gérer des valeurs par défaut

17. COMPLEXITÉ DANS LE CONTROLLER
Un espace trop important est occupé pour le
passage des paramètres à la vue

18. COMPLEXITÉ DANS LE CONTROLLER
Un espace trop important est occupé pour le
passage des paramètres à la vue

19. UTILISATION DES COMPOSANTS
La visibilité des variables n’est pas claire (entre
le template et celui dans lequel il est inclus)
Les composants ne sont pas facilement
réutilisables

20. TESTABILITÉ
Les tests nécessitent les couches du domaine

21. LE PATTERN VIEW MODEL

22. Plusieurs variations : Model View ViewModel,
Model View Presenter, Presentation Model,
MVC …
Objectif : Créer une abstraction entre les
objets du domaine et la présentation

23. View
Model
Objet du
domaine
Objet du
domaine
Assembler

24. LE MODEL
Représentation de la vue
Objet sans logique (DTO)

25. LE MODEL

26. L’ASSEMBLER
Data mapper

27. L’ASSEMBLER

28. LE CONTROLLER

29. LA VUE

30. AVANTAGES

31. APTITUDE AU CHANGEMENT
Le domaine et la vue peuvent évoluer en toute
indépendance
La vue ne possède que les données utiles

32. LOGIQUE DANS LA VUE
La logique peut être déportée dans le View
Model, l’assembler ou un service dédié

33. COMPLEXITÉ DANS LE CONTROLLER
La création des données pour la vue est
déportée dans l’assembler

34. UTILISATION DES COMPOSANTS
A un composant correspond un View Model
La logique de construction est factorisée
Un seul paramètre à passer au template

35. TESTABILITÉ
La création de stub est simple
Le front et le back ont la possibilité de travailler
en parallèle

36. INCONVÉNIENTS

37. Plus de classes

38. -totokiller38
«Avec les frameworks MVC javascript, utiliser des
vues dans une application c’est so 2009.»

39. -BoomBoomStriker
« Cette présentation est nulle, moi j’utilise des APIs. »

40. API

41. Une api est une représentation de ressources

42. ViewControllerDomain

43. ResourceControllerDomain

44. API MODEL

45. API CONTROLLER
Ou utilisez votre serializer favori

46. EN BREF

47. EN BREF
Créer une abstraction représentant la vue ou la ressource
Domaine et présentation varient indépendamment
La vue ne possède aucune logique
Les composants sont facilement identifiables
Testable
S’adapte totalement avec Twig
S’adapte totalement avec une api

48. BIBLIOGRAPHIE
Martin Fowler - Patterns of Enterprise
Application Architecture - Éditions Addison-
Wesley - 2004
Derek Greer - Interactive Application
Architecture Patterns
MSDN

49. MERCI