XXP

mai 2016

lun. mar. mer. jeu. ven. sam. dim.
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

« Les méfaits d’XML (ou gare à la programmation orientée XML) | Accueil | Les méfaits d’XML (ou gare à la programmation orientée XML) »

21 février 2006

Les méfaits d’XML (ou gare à la programmation orientée XML)

XML est devenu envahissant. Au lieu de rester à sa place dans des rôles qui lui vont bien (persistance en format lisible, intéropérabilité des systèmes et patois métiers standardisés), XML s’impose de plus en souvent en tant que socle logiciel, technologie autour de laquelle le reste se construit, hélas au détriment de la maintenabilité du système.

D'abord XML s’infiltre facilement côté data, puisque la plupart des SGBD proposent au moins une méthode d’extraction XML. Il est alors tentant, pour aller vite, de se passer de couche(s) d'objets intermédiaires (objets métiers ou conteneurs non typés genre DataSet) pour n’avoir à gérer que des collections de nœuds XML (voire des chaînes de caractères XML) et à les communiquer à la couche de présentation.

Côté interface graphique, XML peut là encore être central, puisqu’une transformation XSLT peut générer HTML et Javascript à la volée. Ajax est la dernière avancée dans cette voie.
XML derrière, XML devant et pas d’objets intermédiaires, le mal est fait :

  • D’abord parce que chemin faisant on a perdu quelques années de progrès en design logiciel. Exit la programmation orientée objets, son approche intuitive, ses design patterns et bonnes pratiques, bonjour la programmation orientée XML, pour laquelle tout reste à réinventer.
  • Parce qu’ XSLT est l’une des technologies les plus coûteuses (car pénible) à débugger et une des moins adaptée à la monté en complexité.
  • Parce que l’intuition du monde « objets » et de la logique procédurale (« s’il pleut alors je sors mon parapluie ») est remplacé en XSLT comme en XPath par une approche déclarative moins immédiate à appréhender (« il ne pleut pas ou je sors mon parapluie »). La productivité des développeurs en prend probablement un coup.
  • Enfin parce que l’emploi intensif d’XML aboutit souvent à des performances décevantes. Substituer des objets typés et spécialisés (les objets métiers) par des objets génériques et versatiles (les nœuds XML) se paye forcément en performance. Notamment dès qu’un peu de code est nécessaire, on paiera le prix d’un selectSingleNode sur un nœud XML au lieu de l’appel d’une propriété sur un objet. Le pire c’est ensuite de tenter de gagner en performance en travaillant sur le back-end, généralement pour augmenter la part de logique prise en charge par le SGBD. Dans ce cas d’une part le problème n’est pas réglé – le coût d’XSLT, même diminué, demeure – et d’autre part le coût de la maintenance croît encore puisque aux difficultés de débuggage  XSL s’ajoutent celles du débuggage des procédures stockées.

Evidement cela n'enlève rien au charme d'XML, mais il n'est charmant que s'il est invité. Et c'est encore mieux s'il reste discret.

TrackBack

URL TrackBack de cette note:
https://www.typepad.com/services/trackback/6a00d8341c871f53ef00d8347b283453ef

Listed below are links to weblogs that reference Les méfaits d’XML (ou gare à la programmation orientée XML):

Commentaires

Je ne peux qu'être d'accord avec la substance de ce billet. XML n'est pas un marteau. cf http://en.wikipedia.org/wiki/Hammer#Hammers_in_popular_culture

Il y a tout de même un argument qui me gêne, celui de la baisse de productivité liée à la programmation en XSLT. Une telle affirmation va, à mon avis, à l'opposé du sens de l'histoire.
Il faut voir ce qu'est devenu le C++ "moderne" (au sens de Andrei Alexandrescu) ou bien encore ce que va devenir C# dans sa version 3 avec, notamment, linq. La programmation fonctionnelle est en train d'arriver par la grande porte et rester bloqué au point mort sur la programmation impérative n'est pas, à mon avis, le meilleur service à rendre à un développeur.
Il est malheureusement certain que les gros des troupes de "ressources humaines" en développement logiciel nourries dès leur plus jeune age au C, au java et au VB est à des années lumières de cette (r)évolution...

Aaaaah, un commentaire, merci Olivier.

Le débat fonctionnel/impératif (je disais jusqu'à maintenant déclaratif/procédural, qui va ergoter là-dessus ?) a un bel avenir.
Je trouve que sur ce sujet l'histoire tourne en rond. A mon avis le pb de ces technologies (Lisp, Scheme, mais aussi feu DirectAnimation http://www.webdevelopersjournal.com/articles/directx/OvalRotate.htm), c'est d'être difficilement debuggable. Le niveau tutorial est souvent très séduisant, mais le développement de systèmes d'entreprise se heurte au coût de debuggage. Le pire à diagnostiquer c'est quand rien ne se passe : sans breakpoint à placer, il ne reste qu'à retourner à un état où "ça marchait", à ajouter petit à petit les déclarations supposées fautives, et à s'arracher les cheveux pour comprendre pourquoi telle ligne fait basculer l'univers déclaratif vers le néant (un document HTML vide, une animation inanimée…).
Pour XSLT, j'ai constaté en pratique un recours fréquent aux fonctionnalités purement impératives de type "for-each"...
Finalement le seul langage fonctionnel qui ait eu un vrai succès c'est SQL, non ? Son "extension" (N)Hibernate HQL est vraiment pratique au minimum pour éviter du code impératif de tri/sélection. Le peu que j'ai vu de Linq ressemblant pas mal à HQL, je parie sur son succès.

Finalement et contrairement à ce que j'évrivais dans le billet, les énoncés déclaratifs peuvent être plus naturels que les énoncés impératifs.
J'en ai entendu la preuve dans le RER : "arrête ou j't'en colle une". Plus efficace que "si t'arrêtes pas j't'en colle une". :-)

Non ça ne s'adressait pas à moi...

L'utilisation des commentaires est désactivée pour cette note.