Le modèle MVC n’existe pas

Partagez ...
  •  
  •  
  •  
  •  

Le modèle MVC n’existe pas : pourquoi ?

Sous ce titre volontairement provocateur se cache une vérité indéniable. Visitez 10 sites traitant du modèle MVC, vous aurez 10 représentations différentes.
Prenez par exemple un site de référence : Wikipedia. Amusez-vous à comparer la page française et le page anglaise.

1. Les schémas sont différents

a. la version française :

Modèle MVC wikipedia français

b. la version anglophone :

Modèle MVC wikipedia anglais

2. Les rôles sont différents

a. la version française :

  1. Un modèle (Model) contient les données à afficher.
  2. Une vue (View) contient la présentation de l’interface graphique.
  3. Un contrôleur (Controller) contient la logique concernant les actions effectuées par l’utilisateur.

b. la version anglophone :

  1. Le modèle est responsable de la gestion des données de l’application. Il reçoit les entrées utilisateur du contrôleur.
  2. La vue signifie la présentation du modèle dans un format particulier.
  3. Le contrôleur répond à l’entrée utilisateur et effectue des interactions sur les objets du modèle de données. Le contrôleur reçoit l’entrée, optionnellement la valide puis la transmet ensuite au modèle.

Pas étonnant devant un tel flou artistique que les étudiants en informatique récitent parfaitement leur leçon, mais dès qu’on creuse un petit peu, se perdent dans leurs souvenirs scolaires ou de recherches sur le net, à la recherche d’une réponse qui a du sens.

Pourquoi un tel mélange ?

La raison est très simple : on essaie d’appliquer à la création d’applications ou de sites web un concept qui n’a pas été créé pour ça !
Comme le dit wikipedia : MVC a été créé par Trygve Reenskaug lors de sa visite du Palo Alto Research Center (abr. PARC) en 1978. C’est un motif d’architecture logicielle destiné aux interfaces graphiques !
Puis on a trouvé ça tellement génial que petit à petit on a étendu ça aux applications et sites WEB. Sauf que là, on avait d’autres problématiques non définies par ce modèle : l’accès aux données ? La logique métier ? Le routage ? Bref on se retrouve avec beaucoup de trous.
Ces trous, différents designers, frameworks ou autres développeurs ont essayé de les combler, avec plus ou moins de bonheur.
Aujourd’hui on ne peut donc plus parler DU modèle MVC, mais de modèles s’inspirant du concept MVC.

La séparation en couches

Pourquoi a-t-on trouvé ça génial ? Tout simplement parce que ce modèle (design-pattern) oblige à une séparation en couches. Et c’est ça l’élément fondamental du design pattern MVC.
Il est aujourd’hui universellement reconnu par tous les développeurs professionnels que la séparation en couches favorise la maintenance corrective et évolutive d’une application. Elle propose un modèle strict séparant fonctionnellement les différentes parties d’un programme en gestion des interfaces, logique métier, accès aux données … ce qui accélère de manière notable pour un développeur l’identification dans des milliers de lignes de code la partie où on devra appliquer un correctif ou que l’on devra faire évoluer.

Ce que n’est pas le modèle MVC

Outre les deux schémas de wikipedia ci-dessus, parmi les horreurs qu’on trouve sur le net, on peut trouver ce genre de schémas :

mauvais exemple de MVC

Que signifie la flèche de gauche ? Et l’utilisateur attend pendant des siècles sa réponse …

On a aussi une représentation très appréciée des étudiants que je vois :

autre mauvais exemple de MVC

Là, le modèle MVC s’exécute tout seul dans son coin, sans rien demander à personne, bref une parfaite illustration de la roue sans fin. Tout de même, j’aimerais bien savoir ce que représente cette flèche entre la vue et le modèle …
Sauf que si on demande à nos étudiants : si j’ouvre mon navigateur, je vais dans la barre d’adresse, je tape une url complète avec mon action du type https://monsite.com/users/list, alors comme je ne suis pas dans une vue je ne peux actionner le modèle tel que représenté ici ? Et là, un grand moment de solitude …
De plus, les liaisons entre la vue et le modèle sont déconseillées : on respecte la séparation des couches donc c’est le contrôleur qui se charge de la communication.

Et le pompon :

très très mauvais exemple de MVC

On n’a même plus de modèle dans le modèle MVC !!! Un comble ! Par souci d’humanité, je ne citerai pas le site sur lequel j’ai trouvé ce chef d’œuvre.

Ce que devrait être un modèle MVC

Compte tenu de ce qui a été présenté précédemment, des erreurs des schémas ci-dessus, de l’architecture en couches que l’on souhaite atteindre, on pourrait schématiser un modèle MVC ainsi :

Design pattern MVC

Le déclencheur du modèle MVC est une requête lancée par un utilisateur.

Cette requête arrive sur le contrôleur qui fait son travail de vérification d’accréditation, de syntaxe des paramètres de la requête … puis il choisit le modèle qu’il va interroger en fonction de la requête. Fonctionnellement le contrôleur est un simple aiguilleur qui établit les relations les différentes parties du système.

Le modèle renvoie au contrôleur des données (résultat de mises à jour de la base, données requêtées dans la base, code d’erreur …)  qu’il renvoie à la vue qu’il choisit, en fonction du retour du modèle.

La vue modifie son affichage en fonction des données reçues et renvoie le résultat au contrôleur qui renvoie le tout à l’utilisateur (mais en aucun cas la vue ne connaît l’utilisateur comme on peut le voir dans certains schémas).

Si maintenant, on veut rajouter les éléments manquants pour une architecture plus complète, on obtient :

Design pattern MVC complet

Explications :

  • Pour le routeur, c’est simple, il choisit le contrôleur approprié lors de la réception d’une requête. Son rôle s’arrête là.
  • La couche métier est à l’origine de bien des débats. Aujourd’hui on la trouve souvent mélangée au contrôleur. A mon sens, c’est une erreur. A double titre parce qu’historiquement, dans le modèle MVC, on n’avait pas d’objet métier ni de DAO puisqu’il s’agissait d’un modèle destiné aux interfaces graphiques. Ceci dit, le modèle évoluant avec son spectre d’application, vous me direz pourquoi pas ? Et bien tout simplement parce que le contrôleur a déjà beaucoup de chose à faire. Rajouter une couche dans le contrôleur nuit donc à sa lisibilité. La seule condition qui me ferait accepter cela serait que, comme le modèle, le contrôleur soit organisé lui-même en plusieurs couches, ce qui n’est pas le cas actuellement. Donc halte au mélange et on crée une couche à part, dans le modèle, modèle qui représente aussi nos objets métier, la présence de la couche métier n’est donc pas surprenante.
  • Quant à la DAO, sa présence là est évidente.

MVC est-il incontournable ?

Oui au sens de la culture informatique. Maintenant, avec la venue de nouvelles technologies notamment, on s’aperçoit que le modèle MVC présenté ici n’est plus applicable.
Prenons par exemple le cas d’Angular JS. On aura les vues gérées directement par le front, et une communication par API avec le module serveur qui se réduira donc à la partie MC. Le V a disparu.

Il y a également l’apparition de nouveaux modèles pour lesquels MVC a servi d’inspiration, MVVM par exemple, mais aussi HMVC pour sa modularité ou MVC2 plutôt réservé à de petites applications, sans oublier les patterns pour applications mobiles.

Conclusion :

il n’y a pas de design pattern incontournable. Seule la séparation des couches l’est. Et plus le modèle de séparation des couches est un standard, plus il sera bénéfique puisque plus de développeurs le connaîtront.

Quelques idées reçues :

Beaucoup d’étudiants, se fiant à ce qui est écrit sur le net, m’affirment que Symfony ou Laravel respectent le modèle MVC.
D’ailleurs sur la page française de Wikipedia, on le voit écrit !
Symfony : Fabien Potencier (patron de Sensio et accessoirement auteur au moins en grande partie de la version 1 de Symfony) a écrit un article dans lequel il explique pourquoi ils ont fait le choix de ne pas respecter le modèle MVC. Ils ont fait le choix d’une architecture en couches. Et en ça, Fabien Potencier a raison, c’est le cœur de la raison d’être du modèle MVC. C’est l’architecture en couches qui fait qu’une application sera maintenable ou pas.
Vous pouvez trouver cet article ici : what-is-symfony2.
Dommage pour la foultitude d’articles sur le Net qui affirment sans rien y comprendre que Symfony respecte le modèle MVC.

Laravel : Taylor Otwell le créateur de Laravel a lui été un peu plus discret dans ses aveux. En effet il s’est contenté de 2 tweets :

Tweet de Taylor Otwell

Et :

Tweet de Taylor Otwell

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

15 + 11 =

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.