le pattern view model avec symfony2
TRANSCRIPT
LE PATTERN VIEW MODEL AVEC SYMFONY2
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
DE QUOI EST-IL QUESTION ?
ViewControllerDomain
ViewControllerModel
MVC
Presentation
Layered
ViewControllerBusiness Layer
Data Layer
Presentation
Infrastructure
Domain Driven Design
Domain Layer
Application Layer ViewController
Presentation
ViewController
Entity
Clean Architecture
Use Case
Gateway
Implementations
Boundary
Presentation
Vue Controller
Data
WTF Design
Kitten Layer
Unicorns Park
CONTROLLER
VIEW
SIMPLE, MAIS …
Le post suivant
La liste des derniers posts vus
La liste des posts les + vus
Une recommandation de posts
…
QUELS SONT LES PROBLÈMES ?
APTITUDE AU CHANGEMENT
La présentation dépend du domaine
Un changement entraîne des changements dans toutes les couches
Too much knowledge
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
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
COMPLEXITÉ DANS LE CONTROLLER
Un espace trop important est occupé pour le passage des paramètres à la vue
COMPLEXITÉ DANS LE CONTROLLER
Un espace trop important est occupé pour le passage des paramètres à la vue
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
TESTABILITÉ
Les tests nécessitent les couches du domaine
LE PATTERN VIEW MODEL
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
View Model
Objet du domaine
Objet du domaine
Assembler
LE MODEL
Représentation de la vue
Objet sans logique (DTO)
LE MODEL
L’ASSEMBLER
Data mapper
L’ASSEMBLER
LE CONTROLLER
LA VUE
AVANTAGES
APTITUDE AU CHANGEMENT
Le domaine et la vue peuvent évoluer en toute indépendance
La vue ne possède que les données utiles
LOGIQUE DANS LA VUE
La logique peut être déportée dans le View Model, l’assembler ou un service dédié
COMPLEXITÉ DANS LE CONTROLLER
La création des données pour la vue est déportée dans l’assembler
UTILISATION DES COMPOSANTS
A un composant correspond un View Model
La logique de construction est factorisée
Un seul paramètre à passer au template
TESTABILITÉ
La création de stub est simple
Le front et le back ont la possibilité de travailler en parallèle
INCONVÉNIENTS
Plus de classes
-totokiller38
«Avec les frameworks MVC javascript, utiliser des vues dans une application c’est so 2009.»
-BoomBoomStriker
« Cette présentation est nulle, moi j’utilise des APIs. »
API
Une api est une représentation de ressources
ViewControllerDomain
ResourceControllerDomain
API MODEL
API CONTROLLER
Ou utilisez votre serializer favori
EN BREF
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
BIBLIOGRAPHIE
Martin Fowler - Patterns of Enterprise Application Architecture - Éditions Addison-Wesley - 2004
Derek Greer - Interactive Application Architecture Patterns
MSDN
MERCI