Le blog de L'ami S'ami

Bertrand soulève un problème intéressant « la couche de présentation est-elle une couche jetable ?» je vais essayer d’apporter ma pierre à l’édifice de cette analyse, forcément subjective car liée à mon expérience personnelle (n’en tirez donc pas de conclusions hâtives). Avant d’entrer dans le vif du sujet, j’attire juste votre attention sur le terme « jetable ». Il comporte à mon avis une connotation péjorative. Il faut entendre « jetable » dans le sens « moins stable ».

D’autre part, dans ce type d’exercice périlleux, il existe *forcément* des exceptions. Une application dont 99% des fonctionnalités sont purement graphique (un player vidéo, un visualisateur d’images, etc…) sort forcément du cadre de cette réponse. Ici, je m’intéresse essentiellement aux applications de gestion, typiquement multi-couches avec une couche de présentation « classique » (formulaires simples ou complexes, etc…).

Personnellement : oui, je pense que la couche de présentation est l’une des couches les moins stables des trois (UI, Services, Data), sinon la moins stable, car soumise aux incessantes évolutions des technologiques actuelles. Exemple côté Java : Servlet->JSP->Struts->JSF : 4 évolutions en 5-6 ans. Côté serveur ? Et bien, aussi bizarre que cela puisse paraître, celui qui a implémenté il y a 6 ans ses composants serveur avec des Javabeans simples (les fameux POJO) , est aujourd’hui, toujours, sinon plus que jamais d’actualité. Même si on intégrait les EJB dans ce décompte, on aura eu qu’une, voire deux évolutions majeures ces 6 dernières années (EJB 1 et EJB 2). Côté .NET, les MFC furent les premiers à ouvrir la voie, vinrent ensuite les WinForms, puis Avalon pour le client lourd. Côté Web, ASP unmanaged, puis ASP.NET, et demain une hypothétique convergence avec Avalon ..

Non seulement les évolutions sont plus rapides côté client, mais qui a déjà essayé de produire du code IHM 100% propre? Au début, on part avec beaucoup de bonnes intentions, puis de fil en aiguilles, on rajoute 1, 2 puis 10 formulaires. On se dit « tiens, je vais optimiser la création des contrôles et des formulaires dans une classe intermédiaire générique, et ainsi je factoriserais du code ». Et c’est là que tout se gâte :-). Factoriser du code lorsqu’on gère 40 évènements dans un écran contenant 50 champs et autant de contrôles de surface relève du défi. On pense qu’on factorise, mais en réalité on ne factorise pas vraiment. Les appels aux API techniques s’enchevêtrent les unes des autres et on ne résiste pas longtemps à la tentation du diabolique copier/coller vite fait bien fait (le CutAndPaste Pattern ;-)). Puis agacé, on se dit « il doit forcément exister un Framework qui fait ça » . C’est alors qu’entre en scène le fameux Framework générique de présentation. Il fournit des patterns à qui en veut, du MVC, du StateMachine, du NavigationModel, du RequestDispatcher … Une fois qu’on y a passé un temps considérable, on relève la tête et on s’aperçoit que le prochain JSF fournit déjà un modèle de navigation, des taglibs réutilisables et une gestion des évènements typés. Sans compter ceux qui ont passé des heures à écrire des Custom Control ASP.NET 1.0 factorisables avec 90% de code-behind. Une fois ASP.NET v2 arrivé, les voilà contraints à leur plus grand damne de jeter une partie de leur dur labeur désormais intégré au Framework ASP.NET 2.0. Et je vous passe les futurs Avalon, XUL ou Flex qui risque de révolutionner dans les années à venir notre manière de concevoir l’UI .

Bref, écrire une couche de présentation est l’une des tâches les plus ingrates qu’il soit. J’ai dans ma « très courte » vie ;-) vu très peu de code IHM facilement maintenable lorsque la présentation devenait complexe. Seules rares exceptions, les applications multi-canals tirant parti de la génération de code à partir de modèles XML (Cocoon, etc…), et encore...

Si l'outil magique de demain me permet de concevoir cette IHM par simple glisser/déplacer sans une ligne de code, alors on aura atteint la perfection (vous allez rire, mais finalement un peu comme dans VB6). En attendant, il vaut mieux réfléchir à deux fois avant d’investir lourdement et s’acharner à rendre cette couche générique, ce qui ne veut pas dire qu'il ne faille rien faire pour l'améliorer. Mais nativement, des Frameworks tels que ASP.NET ou JSF ou Struts côté Web fournissent déjà un socle minimum de qualité.

J'imagine qu'il existe des dizaines de point de vue différents sur le sujet, n'hésitez pas à les exprimer ici ou sur le blog de Bertrand.