Symfony expliqué à ma maman, 4ème partie : le MVC
Suite aux posts un peu laborieux sur les design patterns et le découplage, il est temps d’être (un peu plus) concret et de raconter la vie d’un ami qui vous veut du bien : le MVC.
Le MVC est un design pattern qui est l’abréviation de Modèle-Vue-Contrôleur, et pour une fois, en anglais ou en français, ça fait les mêmes initiales (Model-View-Controller), donc y aura pas de débat sur comment qu’on doit causer. On raconte que son créateur se nomme Trygve Reenskaug, me demandez pas comment ça se prononce — son créateur, ou disons son théoricien, car comme souvent, on ne l’avait pas forcément attendu pour opérer de cette façon, mais il a mis des mots dessus (ce qui ne diminue pas l’importance de son travail).
Pour tout dire, quiconque a fait seul dans son coin des sites web dynamiques en mettant un peu (beaucoup) les mains dans le cambouis des langages/bases de données/exploitations multiples des mêmes informations, etc, a de fortes chances d’avoir à un certain niveau commencé à appréhender plus ou moins consciemment le MVC – ou alors, il a vraiment beaucoup galéré, et il est un petit peu décédé à l’heure qu’il est.
Moi qui vous parle, enfin vous écrit, avant de lire quelques livres intéressants sur le sujet et de découvrir des frameworks, j’en étais arrivé à travailler systématiquement avec d’un côté des méthodes d’accès aux informations (à peu près bien abstraites du système de base de données), de l’autre des fichiers traitant les sorties (pour le web, pour le XML, pour des usages internes…), et au milieu un ou plusieurs points traitant les actions des utilisateurs et décidant ce qui devait être mis en œuvre.
Bien sûr, n’ayant pas conscience clairement des enjeux de cette division (faute entre autres d’avoir mis des mots dessus ; d’où l’importance de nommer), il traînait de nombreuses erreurs d’organisation affaiblissant souvent pas mal l’ensemble. Mais le fond était là : porté par la nécessité interne des traitements récurrents nécessaires pour une application web, j’avais fait un premier pas sans même le savoir, tel le Monsieur Jourdain des design patterns, dans le monde merveilleux du MVC.
Le MVC, ou comment diviser pour mieux régner
Précisons avant d’aller plus loin que comme tout design pattern[1], MVC n’est pas spécifiquement dédié à une technologie, un langage ou quoique ce soit.
Il concerne de droit toute application avec une interface Homme-Machine, comme on dit (enfin, on dit IHM si on veut avoir l’air au courant), et consiste en une sorte de paradigme de l’organisation de l’application, séparant les données et leur vie (modèle), leur présentation (vue), et la gestion des événements (contrôleur).
Séparer le modèle et la vue repose sur une exigence au fond assez simple, qu’on pourra schématiser comme suit : il faut traiter d’un côté le « fond », de l’autre la « forme ». Je recours aux guillemets, non pas pour pourrir la lecture, mais parce que l’utilisation de ces deux termes et leur séparation semblent aller de soi, or comme tout ce qui « va de soi », elles méritent d’être questionnées. Il est illusoire de croire qu’il y aurait d’un côté du « fond » (du contenu, de la pensée…) et de l’autre de la « forme » (l’expression, qu’elle soit écrite, orale, artistique…)
Autant supposer qu’on peut sans autre forme de procès séparer la musique du son, ou l’objet de sa manifestation — ce fantasme de séparation n’est en fait qu’une autre version de l’illusion platonicienne de la chose en soi, « vraie » chose dont le phénomène serait une version dégradée dans notre pauvre monde d’apparences.
Non pas qu’il n’y ait pas un intérêt théorique capital à pouvoir considérer séparément ces aspects ; mais dans la réalité, je vous le dis, croyez-moi sur parole[2], le phénomène épuise tout ce qu’il y a à être de la chose, et la forme, comme je l’ai déjà formulé dans une note précédente, et exactement forme de son fond et réciproquement. Bref. J’ai clairement entamé un autre post ici, qui verra peut-être le jour une autre fois. Revenons à nos moutons.
Nos moutons sont le M, le V, et le C. Il n’aura échappé à personne, du moins à personne qui aura lu avec un minimum de concentration le billet précédent sur les prises électriques et les grille-pain[3] (mais je reconnais qu’il faut du courage), qu’une organisation isolant bien ces trois aspects d’un programme est comme l’archétype du découplage.
Votre modèle (en gros, les données) peut changer de principe de stockage, de nature même si ça vous chante, pour peu qu’il soit correctement interfacé avec les autres couches du MVC, elles n’y verront que du feu. Le centre nerveux de votre application (le contrôleur, qui réagit aux actions de l’utilisateur et distribue les réponses) peut de son côté traiter n’importe quel type d’entrées et rediriger les sorties vers n’importe quel affichage, i.e. les vues. Vues qui de leur côté se contentent de mettre en forme (grosso modo) des informations, indépendamment de leur origine. J’ai failli dire « se contentent d’afficher », mais en fait, contrairement à ce que son nom laisse croire, une « vue » au sens du MVC ne résulte pas nécessairement en quelque chose de… visuel. Une vue peut-être par exemple un fichier XML, qui vivra sa vie ensuite selon le client (au sens informatique) qui l’a requis.
Quand l’intelligence gagne la matière
L’intérêt très concret de l’application du MVC est qu’il isole les opérations, donc que chacun n’a à s’occuper que de sa partie. Et comme dans la vie, c’est toujours mieux quand chacun ne s’occupe que de ce qui le regarde. Dans ma Normandie natale, on dit « Chacun son champ, les vaches sont bien gardées« . Eh bien on ne peut mieux formuler le principe du MVC.
En termes de développement, cette division conceptuelle vise à organiser les rôles par fonction, et à traduire les différences de nature en séparations opérationnelles. Comme si on faisait rentrer dans la chair du code, qui a priori n’en a que faire, un peu du sens des objets qu’on manipule. En contre-partie, dans un effet de résonance sémantique, j’irais bien jusqu’à dire : de récompense sémantique, le code, initialement « bête », gagne en intelligence d’organisation et d’évolution. Risquons la formule : bien utiliser le MVC, c’est insuffler de l’âme dans la matière. Ouaip. Pas moins.
L’ultime intérêt, non des moindres, est pédagogique : en s’efforçant d’appliquer cette discipline de conception et d’implémentation, on s’oblige à bien comprendre ce qui fait quoi dans son application. Et croyez-moi, c’est pas de la tarte.
Mais, une fois encore, une bonne méthode appliquée avec constance finit par insuffler plus que du mécanisme, et crée de l’intelligence. Et pas que dans le code. Dans le codeur également. C’est toute la puissance de la méthodologie[4] : des idées régulatrices qui dirigent vers un endroit. Et même si on ne sait pas précisément où est l’endroit, on peut travailler à avancer dans la bonne direction, et à bien arpenter le chemin.
Car pour finir sur une touche étymologique du meilleur aloi, c’est précisément de là que vient le mot méthode : μέθα (méta, qui suit) οδός (odos, le chemin).
___________________________________
Image empruntée ici : http://www.marriedtothesea.com/archives/2007/Aug/
________________________________________________- Pour être rigoureux, il faudrait dire que le MVC est en fait une combinaison de trois design patterns : composite, stratégie, et observateur. Ceux que ça intéresse vraiment n’ont qu’à se documenter, hein ; comme dirait l’autre, STFW… [↩]
- C’est une façon de parler, évidemment… Ne me croyez surtout pas sur parole [↩]
- J’ai vérifié, « grille-pain » est invariable, au pluriel, ça ne bouge pas… [↩]
- S’il est besoin de le préciser : je crois en la vertu de la méthode et des méthodologies bien pensées. Je ne crois même qu’à ça. Enfin non, ça n’est pas vrai. Je crois en l’intuition et l’inspiration, parce que j’en ai vu, et même par (rare) fois expérimenté. Mais l’intuition n’est rien sans le travail qui suit. [↩]
Tags : design patterns, framework, méthodologie, MVC, symfony
lundi 15 mars 2010 à 18 h 50 min
[…] This post was mentioned on Twitter by Laurent Le Coustumer, Marc, Pierre Bastoul, Xavier Briand, Florian Labadens and others. Florian Labadens said: RT @laurentLC: a juste le temps de poster – #Symfony expliqué à ma maman, 4ème partie : le MVC http://bit.ly/7ZR8Mf […]
mercredi 17 mars 2010 à 18 h 54 min
[…] propos de ce billet n’est pas de vanter les mérites du design pattern MVC, car ils sont en général bien compris par mes étudiants. C’est plutôt d’en détailler […]
vendredi 02 avril 2010 à 16 h 08 min
Félicitation pour ces articles de qualité. La vulgarisation des projets libres est quelque chose qui fait cruellement défaut dans le monde open-source. Lorsque l’on arrive sur un site d’outil/langage open-source, on peine à trouver où se documenter, où télécharger et on passe par 20 pages de 10 sites différents avant de cliquer sur le lien « Download » (il faut aussi parler anglais) qui ouvrira finalement LE pop-up permettant de télécharger le fichier recherché, dans l’hypothèse également où l’on a trouvé le bon fichier entre « exe », « binary », « archive », « tar.gz », etc. tout ce joyeux jargon que le commun des mortels ne comprend pas.
Donc merci :)
J’aime bien votre façon d’écrire également ! Bien écrit et sérieux mais avec un peu d’humour et un soupçons de langage courant pour la touche Web ;)
Je souhaite notamment vous proposer une petite offre d’emploi qui pourrait intéresser vos lecteurs ou vous-même :
http://bit.ly/ak9cI2 Emploi développeur #PHP #Symfony ,qualités humaines,esprit d’initiative et individus passionnés recherchés
lundi 10 mai 2010 à 18 h 43 min
Bonjour et merci pour ces articles !
Un régal pour mes méninges et pour mes abdos – je me fends la poire !
« des idées régulatrices qui dirigent vers un endroit. Et même si on ne sait pas précisément où est l’endroit, on peut travailler à avancer dans la bonne direction, et à bien arpenter le chemin » m’aura fait penser au Taciturne et à sa maxime – ce n’est pas le chemin de la facilité !
La suite ! La suite ! La suite !!
J’attends un sujet sur la quadrature du cercle ou sur la dispersion « façon puzzle » :-)