Le modèle MVC n’existe pas

  • Auteur/autrice de la publication :
  • Post category:Conception
  • Dernière modification de la publication :Dernière modification :16 février 2023
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 : Wikipédia. 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 Wikipédia : 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 Wikipédia 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 ? Certainement la requête, encore faudrait-il le préciser. 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 …

La vue envoie donc la requête si on se fie à ce schéma.
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 (sans les espaces bien sûr), alors comme je ne suis pas dans une vue je ne peux actionner le modèle tel que représenté ici ?
  • si je clique sur un favori de mon navigateur contenant l’url de mon site, alors, comme je ne suis pas dans une vue, je ne peux actionner le modèle tel que représenté ici ?
  • Comment se passe le tout premier accès à mon site ? Je ne peux pas être dans une vue, puisque je viens d’ouvrir mon navigateur ? ça ne marche pas non plus ? C’est vraiment gênant pour le coup …

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

On a vu que le modèle MVC date de 1978. À l’époque Internet n’existait même pas puisqu’il a été (officiellement) créé le 12 mars 1989 par Tim Berners-Lee.
Lorsqu’on a voulu adapter ce modèle à l’architecture WEB d’une application, aucun framework javascript moderne du type vue, react, angularJS n’existait. Tous les fichiers étaient donc situés sur le serveur, et s’exécutaient sur le serveur. Le concept original MVC est un simple design pattern. Le modèle MVC, adapté au WEB, a donc été créé à la base dans une optique de Backend uniquement.

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 :

Modèle MVC général
Modèle MVC général
 

Le déclencheur du modèle MVC est une requête lancée par un utilisateur. On se moque de l’origine de cette requête (bouton, lien, favori, « ça passe par du javascript » …), dans tous les cas et ce, sans exception, on a une requête provenant d’un client.

Cette requête arrive sur le contrôleur qui fait son travail de vérification d’accréditation, de routage, 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 quasiment 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, choisie 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).

Petit détail assez couramment répandu mais également faux, et qui alimente tous ces schémas erronés que l’on voit sur internet: l’interface utilisateur est souvent confondu avec la vue, c’est pour ça que souvent on dit que l’utilisateur clique sur un bouton dans la vue. Mais ceci est faux.

En effet qu’est le modèle MVC ?

C’est un design pattern d’architecture de code et c’est tout. Donc, le Modèle c’est du code, le Contrôleur, c’est du code et enfin la Vue c’est du code. Point barre.

  • La couche vue c’est les templates et c’est tout.
  • La couche controller contient tout ce qui relève du contrôle (validation requête, validation paramètres, authentification, routing…)
  • La couche modèle contient vos entités, vos repositories, vos règles métier …
    Les règles métier sont intimement liées aux entités qu’elles sont censées gérer,  c’est pourquoi elles appartiennent à cette couche.

C’est pour cela  qu’en regardant une arborescence d’un projet respectant le modèle MVC, on voit (entre autres) les répertoires model, controllers et views (ou templates, suivant les frameworks).

Mais ce que voit l’utilisateur, c’est le résultat de la requête précédente qui consiste en l’agrégat d’une vue et de données (ou de messages d’erreur) fournies par le contrôleur, ce n’est pas la vue !

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

Modèle MVC détaillé
Modèle MVC détaillé

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 choses à 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 DAL, sa présence là est évidente.
  • L’appel à la couche vue est facultatif : lorsque une requête ajax (l’ajax a été pris en compte par la plupart des navigateurs du marché entre 2002 et 2005, donc bien après la création du modèle MVC) est envoyée, la couche controller s’adresse à la couche modèle et renvoie directement les datas au client, qui les affiche dans sa vue précédemment chargée.

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 du serveur. Il faut donc adapter le schéma avec une couche controller qui renvoie du data au client.

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. Même la séparation des couches ne l’est plus, puisqu’on voit apparaître une approche par composant dans les frameworks JS. Mais 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. 

Comment adapter le modèle MVC aux frameworks JS

Comme on l’a vu précédemment, MVC est un modèle qui, pour des raisons de chronologie historique, ne peut se constater que sur un serveur.
Ce modèle ayant apporté une grande satisfaction chez les développeurs, les promoteurs des nouveaux frameworks se sont acharnés, au début au moins, (cf. AngularJS par exemple) à déclarer que leur framework respectait le modèle MVC. Continuons donc ce chapitre dans cette optique un peu approximative, même si là, on sort un peu du modèle MVC tel qu’il a été défini, et s’il s’agit d’un avis plutôt personnel.
La réponse à la question précédente est assez simple lorsque toutes les vues sont gérées directement par les frameworks JS eux-mêmes, c’est-à-dire que les fichiers templates sont gérés directement dans le framework JS, et que ces vues sont regroupées dans une même arbrescence.

La couche vue est donc déportée donc le modèle devient :

Modèle MVC avec framework JS
Modèle MVC avec framework JS

Nota :

  1. Lors de l’utilisation de vues hybrides (ex templates twig contenant du react.js), si on reste avec TOUTES les templates gérées en twig, il s’agit donc du premier modèle MVC présenté, puisque les fichiers sources sont dans une arborescence propre au serveur.
  2. Si vous faites un mix avec de templates gérées par React et d’autres par Twig, légalement vous avez le droit, techniquement, je n’aimerais pas être celui qui reprendra le projet après vous ! En effet, vous contrevenez au principe de base du multicouche sensé faciliter la maintenance. Mais bon, pour la théorie, on peut imaginer un modèle avec une couche vue pour moitié installée sur le serveur, et pour le reste chez le client. Personnellement, je préfère clairement dire que dans ce cas, on ne fait plus du MVC.
  3. Le concept d’une couche « vue » avec un framework ayant une approche par composant est assez contradictoire. MVC ayant pour but de définir une arborescence simple pour vos fichiers de dev est quand même mis à mal dans cette approche. Il ne faut plus hésiter : on n’est plus dans du MVC. On est dans un modèle MC avec, côté client une approche par composant. Après tout, MVC n’est pas la bible et peut être remis en cause.

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

Cet article a 2 commentaires

  1. Christophe

    Aaaaaah enfiiiinnnn !

    Ca fait 3 semaines que j’apprends à développer avec PHP en modèle MVC

    J’ai fais plusieurs tutos et TP, noté les différents schémas « MVC » qui en résultaient et je commençais à en avoir marre de perdre du temps à remettre en question les cours à coups de schémas et de documentations !

    Obligé de faire mes propres schémas parce que rien ne correspondait de ce que je trouvais !

    Grâce à toi me voilà rassuré, chacun y va de son MVC, c’est bien ce qu’il me semblait.

    Merci infiniment (révérence)

  2. iparnet

    Merci Christophe pour ton commentaire.
    Comme tu dis, chacun y va de son MVC, mais tu auras noté que certains sont meilleurs que d’autres 🙂

Répondre à iparnet Annuler la réponse

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