Christophe m’a demandé de préciser ce que j’avais contre le MVC & le n-tiers etc etc.

Alors, MVC, sur le principe, c’est très bien. J’en suis même, en théorie, un ardent défenseur. Le principe, c’est « pour une appli, on a des données (model), on veut les voir (view), et on veut y appliquer des traitements (controler). Et on découple tout ça de manière à ce que (par exemple) si on change l’algorithme de traitement, il y ait normalement pas besoin de changer ni la visualisation des données ni le modèle de données. Très bien.

Là où ça se gâte, c’est que le cloisonnement du modèle MVC, bien souvent, il est dur. Ça veut dire que pour appeler un truc du côté contrôleur quand on est côté vue, faut se manger des callbacks pas possibles et, bien souvent, c’est pénible ET long. Pour l’exemple, la dernière fois que j’ai dû aller rechercher une fonction à la noix de ce type là, ça m’a pris 4 ou 5 heures pour mettre en place ledit callback. On me rétorquera que 1/ c’est que je suis une buse 2/ c’est qu’y’a ptêt un problème avec le framework que j’utilise ; ça n’empêche que par rapport à appeler bêtement une fonction, c’est long.

En pratique, le problème, et tout particulièrement quand on travaille à plusieurs sur du code, c’est que les choses ne sont jamais aussi claires que ça. Déjà, il va en général y avoir du code qu’on aimerait bien avoir des deux côtés (côté contrôleur (on dit aussi métier) et côté vue (on dit aussi présentation)). Techniquement, on est bien d’accord, ça veut dire que quelque part, on sait pas trop où va le code, qu’il faudrait réfléchir, éventuellement le déplacer d’un côté à l’autre et/ou faire les choses plus proprement qu’elles ne sont faites.

Maintenant, considérons la situation suivante. On livre en intégration demain. Il est 16h. J’ai une fonction qui traîne, avec le code kivabien dedans, mais elle est pas du bon côté. J’ai pas de mapping pour faire mon callback. Faire le mapping, ça va relativement vite, sauf qu’il faut recompiler pour mettre le mapping au bon endroit (et ça, c’est long), et que pour mapper, il faut que les paramètres de la fonction soient sérialisables, sinon ça passe pas (et oui, un Boolean, c’est sérializable, un boolean, ça l’est pas. Astuce.) (oui, je fais du Java.) Et, comme dit plus haut, avec toutes ces emm… diverses, faire le mapping proprement, ça peut prendre 4h (avec les divers bugs et autres ennuis) (bon, ça peut aussi prendre un quart d’heure si on s’en tire bien, hein, soyons honnête !!), donc… bin on duplique le code. Moche.

On pourrait contourner ça en ayant une partie de code « commune » qui serait compilée à la fois avec la partie métier et avec la partie présentation. Il faudrait bien sûr faire super gaffe en y mettant quoi que ce soit (c’est un coup à exploser complètement le modèle, donc pas très beau), MAIS quelques fois ça serait intéressant. Je pense en particulier à tout un tas d’utilitaires à la noix qui peuvent très bien servir des deux côtés, traitement de chaînes, tris, etc. Sauf que, évidemment, simplicité et développement à l’arrache obligent, on finirait toujours par y trouver « la fonction qui récupère la liste des gens à qui envoyer un mail pour telle opération » (mbof) et/ou par ne pas y trouver « le petit utilitaire de trois lignes qui appelle le Tokenizer pour parser m chaîne, là ».

En-dehors du code potentiellement duplicable, ya aussi le problème du code qui est « juste pas au bon endroit, du moins il me semble ». Pour moi, une fonction qui envoie un mail à un utilisateur avec des informations sur une instance particulière du modèle, ça va côté présentation (parce que je crée mon mail et je le présente à l’utilisateur). Bon, pour la personne qui a fait la fonction, ça va côté métier. Et là, c’est la lutte. Je sais pas qui a raison (enfin, si, moi 😉 ) mais, techniquement, non, j’ai pas le temps d’en discuter et j’ai pas le temps de corriger quoi que ce soit (rappel : il est 18h et je livre demain en intégration). Donc, on lutte. Pis là on se rend compte qu’il y a deux fichiers de ressources pour les chaînes. Gargl, le fichier en question est côté présentation, il faut donc que je crée le mail côté présentation et que je l’envoie côté métier. Ouiménon, en fait, les chaînes elles étaient dans l’autre fichier. Damned, il est 22h.

Bref, voilà. Le modèle MVC, conceptuellement, c’est très joli. En pratique, entre le code qu’on sait pas où mettre, le code qu’est pas au bon endroit, le code qu’on voudrait bien des deux côtés, le tout dans un environnement d’équipe et à l’arrache, le modèle MVC, ça te pourrit la vie d’une manière monstrueuse.

Quant à l’archi n-tiers… bin mon code métier et mon code présentation, ils sont sur deux serveurs Websphere différents. Il faut lancer le serveur métier avant le serveur présentation, sinon ça plante. Relancer les deux serveurs, ça me prend au moins 10 minutes à chaque fois. La trace d’exécution, elle se fait sur deux serveurs et c’est donc le bordel (d’un côté, ta trace s’arrête sur l’appel au callback, de l’autre, faut déjà voir si elle commence (aka si t’as pas foiré ledit callback)). Debugger du n-tiers, c’est pas marrant.

Voilà. Ceci était mon billet argumenté sur le hurlement primaire de l’autre jour.

Je reprécise donc que dans un environnement parfait où tout le monde sait ce qu’il fait, où personne ne fait de bugs et où on n’a pas (trop) de contrainte de délais, le MVC et le n-tiers, c’est probablement fantastique.