Pourquoi la liaison de données importe-t’elle ?
Note du traducteur : Je n’ai pas traduit certains acronymes principalement parce que l’usage veut qu’ils soient utilisés sous leur forme anglophone. Il est déjà douloureux de jongler avec des abréviations, si en plus il fallait les traduire mentalement… Je n’ose imaginer. Mais voici un petit lexique explicatif.
- API, Application Programming Interface
- Interfaces de Programmation d’Application. Un ensemble d’interfaces de développement pour développer des applications, ou des extensions d’applications.
- XML, eXtensible Markup Language
- Language à balises extensible.
- SAX, Simple API for XML
- Une interface standardisée pour analyser un document XML à partir d’évènements. Contrairement à DOM le document n’est pas manipulable dans sa totalité et n’est manipulé que par fragments.
- DOM, Document Object Model
- Modèle Objet de Documents. Une interface standardisée par le w3c pour manipuler l’arbre syntaxique d’un document (XML). S’oppose à SAX en cela qu’il construit une représentation mémoire du document pour le manipuler.
- JDOM
- Implémentation en Java des interfaces DOM.
- JAXP, Java API for XML Processing
- Ces API supportent le traitement de documents XML en utilisant DOM, SAX et XSLT.
- IDE, Integrated Development Environment
- Environnement de Développement Intégré.
Je sais ce que vous pensez : « Ainsi on va encore me dire que j’ai besoin d’une nouvelle API pour travailler avec du XML. Allez ! Laissez-moi faire une pause ! ». Bien, en fait c’est exactement ce que je m’apprétais à vous dire ; cependant, je vais le faire à la façon O’Reilly, qui est de vous donner des faits, et vous laissez décider par vous même. Mais commençons par un petit retour en arrière.
La liaison de données (NdT : en bon anglais data binding) est une API pour travailler avec du XML. Pour ce qui concerne cet article je vais faire le point sur les APIs écrites en Java. C’est en relation directe avec mon nouveau livre, Java and XML Data Binding (NdT : en anglais). Le livre explique comment utiliser la liaison de données, et non pourquoi. Cela m’a conduit à écrire cet article d’introduction, qui devrait répondre à la question « Qui est concerné ? ». En d’autres termes, vous avez probablement besoin d’une bonne raison pour vous ammener à sortir et dépenser votre argent, si durement gagné, dans un nouveau livre à la couverture animalière et j’espère bien vous en donner plusieurs dans cet article.
La liaison de données est, dans une coquille de noix (nous sommes chez O’Reilly après tout [NdT : référence à la collection "in a nutshell" de l'éditeur]), permet d’associer des données à partir d’un fichier XML vers un objet Java, et inversement. Bien entendu, il n’y a rien de nouveau pour l’univers de Java et de XML puisqu’il existe de nombreuses APIs qui permettent des variations sur ce comportement : SAX, DOM, JDOM, dom4j, JAXP, etc. Cette liste continue encore et encore, toutefois, la liaison des données à quelque chose d’unique qui vaut la peine de s’y plonger un peu. Chacune des API que je viens de mentionner est centrée sur la notion de document. Cela veut dire que vous manipulez des données dans une représentation XML définie. En d’autres termes, vous allez récupérer le contenu d’un élément, la valeur d’un attribut ou le nom d’une référence d’entité. Le problème de cette approche est qu’il vous oblige à travailler dans une structure XML.
La liaison de données part du principe que votre priorité est définie par le métier, et non par XML. En lieu et place d’éléments et d’attributs, vous souhaitez travailler avec des gens, des noms, des adresses et des numéros de téléphone. Vous souhaitez faire abstraction d’XML et aller directement aux données contenues dans le document XML, mais vous souhaitez également ne pas avoir à vous frayer un chemin à travers la sémantique d’XML pour le faire. Pour cette raison, la liaison de données permet une association de données XML (et non pas de structures) vers des classes métiers écrites en Java. Ces classes sont définies par l’utilisateur, il peut donc y avoir une classe Personne, une classe Adresse, ou un membre ville de type chaîne. L’API de la liaison de données prend en charge la transformation des éléments et attributs en type fonctionnels personnalisés. Le résultat est que vous pouvez appeller des méthodes comme setEtat(String etat) et getAdresse() plutôt que setContent(String contenuDElement) et getAttributes(). Les différences, et les avantages, doivent être évidents.
Donc nous en voici au « pourquoi » de la question. Dans l’hypothèse où vous ne vous rendriez pas compte de la façon dont cela peut vous aider, j’aimerai vous indiquer quelques cas d’utilisation typiques de la liaison de données. Il est certain que voudrez utiliser des APIs de bas niveau comme SAX et DOM pour manipuler des données dont la structure peut changer, mais pour des documents orientés-métier et stables, la liaison de données pourrait bien être la solution que vous recherchiez. Voyons si vous n’avez pas du code qui soit au moins dans l’une des catégories suivantes :
1. Fichiers de configuration
À un moment donnée nous avons tous à écrire du code pour extraire des information de fichiers de configurations. Puisqu’ils sont presque tous en train de migrer vers des formats XML, vous finissez en écrivant des gestionnaires SAX ou du code de manipulation du DOM pour fournir un moyen de convertir entre XML et vos données effectives. Cependant, cela prend un temps plutôt ennuyeux, d’autant plus que le format d’un fichier de configuration change rarement.
Plutot que persister dans cette approche inadéquate, envisagez l’utilisation de la liaison de données. Vous pourriez prendre le fichier de configuration suivant :
<?xml version="1.0"?>
<configuration-serveur>
<nom-machine>terres-du-milieu.com</nom-machine>
<services>
<oueb port="80">
<racineDesDoc>/www</racineDesDoc>
</oueb>
<oueb port="8001" admin="true">
<racineDesDoc>/admin</racineDesDoc>
</oueb>
<telnet port="9769" />
</services>
</configuration-serveur>Plutôt qu’analyser ceci, le manipuler, se soucier des espaces et d’une foule de specificités qui n’ont rien à voir avec vos données, imaginez que vous écrivez tout simplement le code suivant :
// Transforme l'XML en objet Java
ConfigurationServeur confServeur = ConfigurationServeur.unmarshal(new File("config.xml"));Vous vous attendiez probablement à bien plus de code. Cependant cette simple ligne gère la conversion des données. Vous pourriez maintenant effectuer des opérations comme celle-ci :
System.out.println("Nom de machine: " + confServeur.getNomMachine());
ServiceTelnet serviceTelnet = confServeur.getServices().get("telnet");
serviceTelnet.setPort(2010);2. Éditeur avec Interface Utilisateur Graphique (NdT : GUI en bon anglais ou IHM en français)
Une des tâches les plus courantes qui ait toujours été consiste à gérer le problème de la correspondance entre les évènements dans un éditeur avec IHM et les données stockées sur disque. Comme pour les fichiers de configurations, XML est devenu un média favori pour de telles données. Toutefois, il persiste le problème qui consiste à créer un système de notification entre ce qui est à l’écran (ce que l’utilisateur saisi) et ce qui se trouve sur le disque.
Il est aujourd’hui relativement douloureux d’écrire du code SAX ou DOM pour réagir à chaque pression de touche, mais il est tout autant couteux de conserver un arbre DOM en mémoire. D’un autre coté, la liaison de données peut à nouveau fournir une réponse.
// Méthode pour mettre à jour le tampon courant
public void onKeyPress(char key) {
// Modifie l'objet tampon
paneCourant.getBuffer().append(key);
}
// Méthode pour écrire les changements actuels sur le disque
// après une demande de sauvegarde
public void onSave() {
// Utilise la liaison de données pour reconvertir en XML
paneCourant.marshal(unFichier);
}Dans la première méthode, l’objet paneCourant est la représentation de données XML stockées sur le disque. Ce n’est pas une construction spécifique à XML, grace à l’utilisation de la liaison de données, mais bien plus une représentation spécifique à l’IDE. Il peut avoir des propriétés visuelles, un état et même un historique des actions de l’utilisateur, toutes correspondant à des champs XML. Dans la méthode onKeyPress(), le tampon est modifié, rafraichissant la version en mémoire.
Dans la méthode onSave(), cette représentation est écrite sur le disque, et toutes les préférences, tampons et autres données sont mises à jour. Cependant, aucune connaissance en XML n’était nécessaire, et l’objet paneCourant n’encombre pas la mémoire avec tout un tas de sémantique XML inutile dans un contexte métier.
3. Stockage en XML
Jusqu’à présent j’ai mentionné deux cas d’utilisation très généraux. Cependant ils sont semblables en cela qu’il doivent tout deux écrire des données dans des fichiers XML. Bien entendu le problème de la persistence de données en XML étaye chacun de ces exemples. XML est non seulement utile pour stocker des données dans fichiers à-plat, mais il peut également être utilisé pour convertir des données dans une base de données XML, ou un serveur d’annuaire acceptant le format XML. Dans chacune de ces situations, vous aurez à écrire du code qui prend les données de votre application et les convertit dans chaqu’un des formats utilisables. Bien évidemment, cela ressemble beaucoup à ce que fait la liaison de données ! Ainsi, à chaque fois que vous devez rapidement convertir des données en XML, la liaison de données devient une solution possible. Vous avez déjà vu qu’avec un simple appel à la méthode marshall() cette conversion de Java vers XML est possible.
En plus de tout cela, je discute dans mon livre de modèle applicatifs (NdT : framework) qui vous permettent de faire cela avec n’importe quelle classe et pas seulement une qui soit crée par des outils de liaison de données. Dans ces cas, vous pouvez utiliser un encodeur externe pour convertir un objet quelconque sous une forme XML :
Encodeur.marshal(monObjetPerso, unFichier);
Encodeur.marshal(autreObjet, monFlotDeSortie);Dans les deux cas la persistence en XML devient triviale, plutôt qu’être un projet parallèle que vous auriez dû passer des semaines à écrire, déboguer et affiner.
4. Modélisation de données
C’est un moyen peu connu, mais très sexy, de gérer les données d’une application de façon visuelle. Il existe des approches très bien connues et comprises pour prendre des documents XML et les formatter pour un rendu visuel, XSLT offre un moyen simple pour faire cela, et FO (Formatting Objects [NdT : Objets de mise en forme]) peut combler l’espace entre XML et les fichiers PDF. Cependant, jusqu’à maintenant, il n’y avait pas de façon simple pour facilement (surlignez « facilement ») convertir vos données métiers en XML. Avec la liaison de données, ce moyen est maintenant à la portée des développeurs.
En combinant ces éléments ensemble, il est possible d’utiliser la liaison de données pour convertir des données applicatives ou métier dans un format XML. Ce format XML peut alors être traité par XSLT ou un processeur FO pour produire des résultats graphiques, ou convertir ces informations dans un format binaire comme le format PDF d’Adobe. Cela signifie qu’en l’espace de quelques heures, plutôt qu’en plusieurs semaines, vous pourriez prendre tous les objets des applications de votre système, les convertir dans une représentation XML, traiter ces représentation à travers un traducteur, et distribuer des fichiers PDF agréablement formattés à la totalité de votre équipe, un quorum du marketing, ou même à votre directeur technique si impatient. Plutôt sympa !
5. Échange de données
Ce cas d’utilisation particulier est celui où vous avez une équipe au dimensionnement plus important et devez déléguer la responsabilité de données à des sous-ensembles de cette équipe. Il est courant dans ce cas d’avoir une spécification pour obtenir des données (là encore en XML) et fournir ces données dans un format utilisable par les autres groupes. C’est un contexte typique où l’utilisation de SAX et DOM s’impose pour charger les données pour ensuite les encapsuler ou les convertir dans des objets dédiés au métier de telle sorte que les autres groupes puissent les comprendre sans avoir à connaitre les API Java et XML. Une fois encore cette fonction est complètement gérée par les API de liaison de données.
Dans les faits, la tâche consistant à écrire du code SAX, DOM ou de conversion est totalement éliminée, et vous pouvez continuer sur des tâches plus intéressantes. À travers l’encodage (conversion en XML [NdT : marshalling]) et le décodage (conversion à partir de l’XML [NdT : unmarshalling]), il est trivial de charger des données XML et de les manipuler d’une façon purement fonctionnelle.
Je sais qu’il ne s’agit que de quelques cas d’utilisation simples, mais j’aurais bien des difficultés à imaginer que qui que ce soit ne puisse correspondre à au moins l’un, si ce n’est plusieurs, de ces exemples. Ils se produisent encore et encore, et avec la liaison de données ils peuvent être gérés plus facilement que jamais. Au lieu de passer votre temps avec les APIs de plus bas niveau (au moins dans ces situations), relaxez-vous, prenez un peu de temps et expédiez quelques lignes de liaisons de données pour prendre en charge le problème.
Et pendant que vous en êtes là, vous pourriez avoir envie de vous saisir de Java and XML Data Binding. Il vous montre comment, et en détails, gérer ces tâches, couvre quatres implémentation différentes de liaison de données, et vous aidera à faire votre travail.
Textes originaux en anglais sur O’Reilly : Why Data Binding Matters par Brett McLaughlin
Chargement
Commentaires récents