le pattern view model avec symfony2

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