Avec l’émergence de l’AOP (Aspect Oriented Programming) et l’IoC (Invertion of Control), on voit fleurir de plus en plus de développement reposant sur l’utilisation d’XML au plus près du code. L’inconvénient majeur (d’où ce billet) que j’y vois est l’utilisation abusive de XML (voire HTML…je vais détaillé un peu plus loin) pour remplacer du code Java ou d’un autre langage. Je ne nie absolument pas la valeur que représente l’IoC, ce qui m’interroge c’est: Pourquoi vouloir utiliser un support tel que le XML pour fraire de la programmation alors qu’il n’est absolument pas fait pour cela. Cela va au delà du couple XML/IoC, on peut parler de HTML/Fit ou encore XML/BPELJ. Lier des composants ou process de haut niveau entre eux de manière découplée avec une configuration en XML à tout a fait du sens. Cependant, plus l’intégration entre ces composant devient intriquée, plus la configuration devient complexe, in-maintenable, sensible aux moindres changement. Pour le BPEL, c’est la même chose, quand l’interaction entre les process devient complexe au point de devoir faire des boucles, il est temps de se demander si on ne doit pas plutôt utiliser un vrai langage de programmation qui se chargera de masquer cette complexité. Dernier exemple: HTML/Fit, qui est un framework de test permettant a des “business analyst” ou “Ingénieurs Qualité” d’écrire des tests en HTML pour valider une fonctionnalité. Cela fonctionne très bien, jusqu’a moment ou une voit apparaitre quasiment des lignes de code dans les ligne de tableau Fit. Il est alors grand temps d’écrire une fiterie de plus haut qui va masquer ce pseudo-code, sinon il faudra être développeur pour pouvoir écrire un test…et c’est exactement l’inverse qui est recherché.
D’une manière générale, laissons aux langages de programmation la responsabilité de cacher la complexité…ou tout simplement les détails d’implémentation, et laissons au XML (ou HTML) la configuration de haut niveau compréhensible à tout le monde.