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.
Les commentaires récents