MVC, ou modèle-vue-contrôleur (model-view-controller en anglais), est ce qu’on appelle un modèle d’architecture logicielle. Ce type d’architecture, aujourd’hui très répandu dans les projets d’applications web, doit son succès notamment à sa forte maintenabilité et à sa facilité à être utilisé en travail collaboratif.
Mais, comment fonctionne exactement le pattern MVC ? Quel est son historique ? A-t-il des concurrents ?
Réponses dans cet article !
Historique
Le pattern modèle-vue-contrôleur n’est pas nouveau. Il a été théorisé pour la première fois en 1978 par l’informaticien norvégien Trygve Reenskaug, puis réellement introduit en programmation à partir de la fin des années 80.
Aujourd’hui, il est très largement utilisé, particulièrement par les frameworks back-end.
Parmi ceux qui ont adopté ce schéma, on peut par exemple citer Spring MVC (Java), Symfony (PHP), Laravel (PHP également) ou encore Django (Python).
Mais certains frameworks front-end ont aussi adopté ce type de découpage, par exemple Angular en TypeScript, contrairement à React qui, comme on le verra, se base sur une architecture différente.
Découpage MVC
Maintenant, voyons un peu plus en détails comment s’organise ce pattern de conception en découpant ses trois composantes : le modèle, la vue et le contrôleur.
Modèle
Le modèle, ou model, représente les données qui vont être utilisées dans l’application web. C’est ici que va être stockée la data, et tout ce qui permet de la modifier (getters, setters, etc.), que ça soit en local en en distant (base de données).
Ce sont littéralement des modèles de données.
Vue
La vue, ou view, c’est l’interface graphique de l’application. C’est via cet élément que vont se faire les interactions entre l’utilisateur et le code métier. Elle ne contient presque aucune logique (contrairement à l’architecture concurrente de MVC dont on parlera plus loin), son but est de construire, à partir de ce que renvoie le serveur, une interface et de l’afficher à l’utilisateur.
Contrôleur
Le contrôleur, ou controller, est l’élément qui contient la logique métier. C’est ici que sont la plupart des algorithmes, calculs, etc.
C’est aussi l’intermédiaire principal entre la vue et le modèle. Par exemple, la vue soumet un formulaire au contrôleur, qui gère sa validation via du code métier, et demande au modèle de faire des modifications dans la base de données.
Exemple
On a défini ce que sont les trois composantes du pattern, mais ça reste une explication théorique. Pour mieux comprendre ce fonctionnement, nous allons voir un cas d’utilisation concret.
Prenons l’exemple de application web d’une banque.
On aurait dans les models les modèles de données des comptes, clients, transactions, etc. Ainsi que tout ce qui permet de les transformer (changer l’adresse d’un client, ajouter ou débiter une somme sur son compte, etc.).
Les vues seraient les interfaces auxquelles accéderaient les utilisateurs : page du compte, historique des transactions, formulaire de virement, etc.
Et les contrôleurs, eux, seraient les responsables de toute la logique : vérification que le format de l’adresse est correct pour le changement, vérification du provisionnement d’un compte pour le virement, etc.
Voici un exemple d’utilisation : l’utilisateur se connecte via une vue, le contrôleur vérifie que ses identifiants sont corrects, il créé le modèle de l’utilisateur et renvoie une autre vue avec les données remplies.
Pour schématiser, voilà les différents échanges qui se font au sein d’une application respectant le pattern MVC :
Exemples d’architectures MVC
On en a rapidement parlé, mais revenons un peu sur les frameworks et outils qui utilisent MVC.
Il faut bien comprendre que MVC est devenu une norme, ce pattern est donc utilisé partout dans le monde du développement.
Voici une liste un peu plus complète :
- ASP.NET MVC, s’appuyant sur le framework .NET ;
- QT, en C++ ;
- Backbone.js, en JavaScript ;
- Angular, en TypeScript ;
- Spring et Struts, en Java ;
- La plupart si ce n’est tous les frameworks PHP (Symfony, Zend, CakePHP, Laravel, etc.) ;
- Django, avec Python ;
- Ruby on Rails, en Ruby.
On ne peut que constater l’omniprésence de MVC !
Les avantages et inconvénients du pattern MVC
Maintenant que l’architecture MVC est plus claire, voyons quels sont les avantages et inconvénients à utiliser ce pattern.
Avantages
Faisons une liste des avantages qu’a l’architecture MVC :
- Facile à maintenir, de par sa séparation obligatoire en fichiers et logique ;
- Le développement peut se faire à plusieurs niveaux en parallèle (création des vues par un développeur freelance front pendant qu’un développeur back travailler sur les contrôleurs) ;
- La décorrélation des vues et de la logique permet de tester le code de manière plus simple et efficace, du moins en théorie.
Inconvénients
Mais si il y a des avantages à utiliser la logique MVC, elle possède aussi des inconvénients :
- Il y a des difficultés à utiliser le MVC avec le développement front-end moderne (utilisation de frameworks fronts orientés composants) ;
- Le peu de souplesse laissé par le pattern peut poser des problèmes si on souhaite utiliser des outils tiers ;
- Les interactions entre les différents modèles et vues peuvent être nombreuses et sont bidirectionnelles (la modification d’un ou plusieurs modèles peut provoquer la mise à jour d’une ou plusieurs vues, et inversement), ce qui complique le développement dans certains cas d’utilisation.
Architecture MVC vs architecture Flux
C’est ce dernier inconvénient qui a forcé Facebook à mettre de côté le pattern MVC pour créer sa propre architecture : Flux.
Contexte
Pour le contexte, alors que Facebook travaillait sur son système de messagerie, les développeurs ont rencontré exactement le problème dont on a parlé dans les inconvénients : les modèles et vues se mélangeaient les uns les autres.
Dans la vue principale de messagerie devait être affichées deux « sous-vues » : une affichant simplement le nombre de conversations non lues, l’autre affichant la liste des conversations, avec celles non lues en surligné (pour les démarquer des autres). Le problème était le suivant : marquer une seule conversation en lue forçait la mise à jour du modèle, mise à jour forçant le rafraichissement des autres vues lui étant liées. Ce qui n’était ni souhaitable ni nécessaire.
D’où la création de Flux.
L’architecture Flux
Comme le montre le schéma suivant (que nous allons détailler), la principale différence entre MVC et Flux, est que le second implémente un flux de données unidirectionnel. Alors que MVC permet des échanges bidirectionnels, qui peuvent partir un peu dans tous les sens, comme dans l’exemple précédent.
Comme on le voit, l’architecture Flux se base sur quatre éléments :
- Les actions : une action est littéralement une action qui va déclencher un évènement ; elle est caractérisée par un type et des données ;
- Le store : c’est dans le store que sont stockées les données. On pourrait imaginer le store comme un super model MVC ;
- Le dispatcher : le dispatcher, qui porte bien son nom, dispatche les actions vers le store (qui va lui exécuter le code métier) ;
- Les views : les vues se rapprochent plus ou moins des vues de MVC dans le sens où elles sont l’interface entre l’utilisateur et le produit ; elles ont cependant plus de code logique. Elles écoutent les changements effectués dans le store et se mettent à jour en fonction de ces derniers.
Si vous venez du monde React, tous ces éléments vous sont déjà familiers.
En fait, ce qu’apporte réellement Flux (ou plutôt son approche de gestion autour d’évènements) par rapport à MVC, c’est un meilleur support des architectures front-end modernes basées sur des composants, comme… React !
Là où faire communiquer des vues « soeurs » était difficile avec MVC, Flux est venu simplifier tout ça grâce à ses actions et à son store.
MVC ou Flux, quelle est la meilleure architecture ?
En fait, la comparaison n’a pas forcément lieu d’être. L’architecture Flux est née pour résoudre une problématique de MVC, il faut plutôt la voir comme une évolution de ce pattern plutôt que comme un concurrent.
Cette évolution a ajouté une touche de complexité à la compréhension et à la mise en place d’une webapp, mais c’est au profit d’une scalabilité plus importante.
React (et sa version mobile React Native) est aujourd’hui tellement utilisé qu’on pourrait dire que le pattern Flux est en quelque sorte devenu une nouvelle norme, lui aussi.
Conclusion
Comme on l’a vu au long de cet article, MVC est un pattern de développement aujourd’hui présent presque partout.
Basé sur ses trois éléments (modèle, vue, contrôleur), il permet d’uniformiser un développement, très utile pour un travail en équipe.
Cependant, il a ses avantages et inconvénients, inconvénients qui ont poussé à l’émergence de son évolution, Flux, très utilisé aujourd’hui via React.
Le concept de MVC n’est toujours pas clair pour vous ? Posez vos questions en commentaire !
