Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Le pattern View Model avec Symfony2
Similaire à Le pattern View Model avec Symfony2 (20)
Le pattern View Model avec 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 ?
- 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
- 24. LE MODEL Représentation de la vue Objet sans logique (DTO)
- 25. LE MODEL
- 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
- 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