Le dogme du MVC

Intro

Il fut un temps où le web était développé “à l’arrache”, en témoignent les divers outils de type CMS ou de forum dans leurs premières versions. Puis une mode est apparue : le MVC.

Dans mon ancien blog, je citais la documentation de PHP à propos de ce MVC qui en fait n’a rien de très précis, est souvent mal interprété et est loin de la panacée promise.

Je suivais cette citation de considérations techniques sur “comment faire un MVC sur le web”, puisque le MVC sur le web ne ressemble pas tout ? fait au MVC dans une application bureau qu’on peut voir avec JAVA par exemple.

Mon expérience

Je me suis rendu compte durant mon année, et notamment durant le projet “Hackenbush” combien ces considérations étaient vaines et combien la citation de la documentation de PHP était réaliste.

En effet en appelant “mvc” un peu près toutes les architectures des framework php (je connais désormais CodeIgniter et Symfony), l’architecture utilisée sur ce blog (qui est une sorte de Code Igniter ad hoc) ainsi que le MVC que j’ai utilisé sur mon application javascript Hackenbush, on croit vite que c’est l’architecture la plus plébiscitée (Symfony) qui est la meilleure.

Je l’ai cru, et j’ai expérimenté, ainsi que tous mes condisciples, de sacrées déconvenues, autant quand il a fallu coder que quand il a fallu soutenir notre projet ? l’oral.

En effet, pour beaucoup d’entre nous, à force de chercher une architecture “divine” qui serait l’exemple type du MVC, nous avions oublié le principe de base de tout patron de conception ou d’architecture : nous organiser et nous offrir un vocabulaire commun qui nous permette de documenter notre application.

En effet, finalement quelque soit le MVC que vous utilisez, s’il est clair dans votre esprit (i.e si lorsque vous créez une classe vous ne réfléchissez même pas ? savoir dans quel dossier vous la mettez) et qu’il est correctement documenté (si vous travaillez en équipe ou qu’une API publique est prévue), ce MVC là ne sera peut être pas la norme de Fabien Potencier, mais il sera très sûrement adpaté à votre utilisation et donc :

  • Ne vous fera pas perdre de performances
  • Vous fera gagner du temps
  • Sera facilement maintenable

J’ai donc aujourd’hui quatre grandes expériences (à mon niveau hein) du MVC:

-Mon projet de première année, en programmation procédurale. Même si la conception du MVC m’avait posé quelques maux de têtes, avec “@CyrilChcod” nous avions rapidement mis tout à plat et fait un MVC qui nous correspondait. Et ça marchait ! Malgré la programmation procédurale, nous avions la réusabilité du code, la clarté et le sens. Et nous ne perdions pas de temps à rien.

-Ma mission auprès de l’ isen concept : qui m’a fait prendre conscience du potentiel des bundles de Symfony 2. Je devais migrer un site qui avait été développé sur CodeIgniter mais qui était plus prisonnier de ce framework que utilisateur. J’ai moi même eu du mal ? faire la jointure des deux projets et ça s’est soldé par un échec relatif (non respect de la deadline). J’ai essayé de reprendre par la suite Symfony2 pour un projet personnel mais le manque de temps et surtout une erreur de conception dans le projet initial m’ont fait un peu arrêter, surtout que j’avais une idée en tête à côté.

-Mon projet de seconde année, Hackenbush pour le petit nom. Ce projet était uniquement en JavaScript + un peu d’ajax. Deux contraintes majeur cadraient ce projet : MVC et POO. Et l? ça a été la catastrophe. Autant notre enseignant nous avait très bien expliqué la POO et une grande partie de la classe maîtrisait les grands concept, puis, ils a réussi ? recadrer et relancer eux qui avaient juste utilisé la POO comme une contrainte supplémentaire (donc des setters/getters pour faire “style” par exemple), autant il s’est lui même emmêlé les pinceaux sur le MVC. Je dois clairement l’avouer, bien que certains points ont été parfaitement maîtrisé par @qfrery et moi, autant nous nous sommes enfoncé (en partie ? cause de moi) dans des contraintes assez lourdes qui nous ont pris du temps de conception tout en ne séparant pas correctement certains morceaux de nos contrôleurs. Nous avons été sanctionnés ? ce propos (assez durement d’ailleurs) mais pour autant, notre code était très lisible. Au moins un objectif d’atteint, vous ne croyez pas?

-Une application androïd que je développe pour et avec des amis dans l’optique du jeu Guild Wars 2. On ne parle plus tout ? fait de développement web, mais il faut savoir que j’arrive sur android avec… zéro connaissance dans le truc. Tout juste la lecture (vitesse grand V parce que au fur et ? mesure que vous avancez, les tutos, ça énerve) d’un tutoriel. Pour le coup j’ai abandonné totalement l’idée d’aller sur le site du zéro depuis que j’ai été déçu par le cours sur le C++ que mon prof a largement dépassé autant en contenu qu’en pédagogie, ce même si la pédagogie est sensée être la force du site du zéro.

Je disais donc, j’ai commencé de manière totalement autodidacte, avec pour connaissance en JAVA que le fais que :

-on peut faire de l’overloading (contrairement ? PHP)

-tout est typé

-il faut faire “import” de tout ce qui n’est pas dans notre package au début du fichier

-on peut dire qu’une méthode peut lancer une exception via throws (comme en C++)

Bien aidé par mon IDE, la doc en ligne et pour un problème en particulier par la communauté du sdz (tout compte fait, la communauté reste cool), j’ai entamé ? tâtons le développement de cette application. J’avais quelques schémas de principe, mais je me suis rapidement buter aux problèmes des AsyncTask, du layoutInflater etc. Au résultat, mes schémas ont totalement changé et j’ai décidé de faire un MVC. Comme ce dernier ne m’étais pas imposé, je n’ai eu aucun complexe ? l’utiliser comme bon me semblait. Eh bien ça a clairement bien fonctionné. Mon code est peut être un peu lourd aux yeux d’un pro. Mais j’ai clairement séparé toutes les tâches entre un modèle/couche métier, une vue/widget et un contrôleur qui fait le lien logique entre les deux.

Je sais exactement où mettre chaque code. Une grande partie de mes codes est totalement générique et donne (enfin ai-je envie de dire) tout son intérêt aux concepts de classes abstraites et d’interfaces. Je retrouve dans le développement de cette application les mêmes sensations que lors du premier projet (et ça fait un bien fou !!) avec en plus le pouvoir et la clarté de la POO !

>TL;DR

Ecrit par : tl;dr

Si tu es mal ? l’aise avec ton patron de conception c’est qu’il est gênant pour ton application.

Leave a Reply

Your email address will not be published. Required fields are marked *