ORM (Object-Relational Mapping)

des objets Java puis mettre à jour la base de données pour refléter les modifications que l’utilisateur a apportées au contenu de ces objets. En 1999, sont apparus les EJB (Enterprise JavaBeans) J2EE afin de résoudre le problème de discordance d’impédance.

Mais la plupart des développeurs, moi y compris, ont jugé les EJB Entity Beans encombrants et difficiles à utiliser. Et donc nous avons écrit nos propres outils ORM. Des dizaines de ces ORM sont proposés en frameworks ORM open-source. Un ORM (object-relational mapping) permet d’associer des données relationnelles à des objets Java dans XML. La figure 1 mappe la table PEOPLE de la figure 2 à la classe Java Person de la figure 3. Important : la classe Person est un POJO (Plain Old Java Object). Un POJO est essentiellement une structure de données dépourvue de toute logique de gestion. Les ORM fournissent des API qui peuplent les POJO à partir des requêtes du genre SQL. Vous pouvez ensuite utiliser d’autres méthodes ORM pour apporter des ajouts, des modifications et des suppressions aux POJO persistants dans la base de données.

Parmi les dizaines d’ORM disponibles, j’ai utilisé Hibernate (hibernate.org), OJB (Object Relational Bridge) d’Apache – db.apache.org/ojb) et iBatis (ibatis.apache.org). OJB est l’un des quelques frameworks ORM open-source qui implémentent la spécification JDO (Java Data Objects), JSR 12 (jcp.org/en/jsr/detail?id=12).

Il semble bien que le fait d’utiliser un ORM qui met en oeuvre une API standard soit une bonne idée : il est bon de savoir que vous pouvez remplacer une implémentation JDO par une autre. Sachez cependant qu’il existe deux types de standard : un ratifié par une organisation et un autre qui s’impose par suite de son acceptation massive dans une industrie. Une API standardisée par une organisation n’est pas forcément intéressante, comme nous l’avons vu avec EJB 1 et EJB 2. Un standard ORM ratifié plus récent est l’API Java Persistence, qui est une sous-spécification de JSR 220 Enterprise JavaBeans (jcp.org/en/ jsr/detail?id=220). D’après le responsable de la spécification JSR 220, la mise en oeuvre d’Hibernate a eu une influence importante sur EJB 3.0 (le créateur d’Hibernate, Gavin King, fait partie de l’équipe JSR 220). Hibernate 3.2 offre deux API : JPA et Hibernate, cette dernière étant un superensemble de JPA.

A noter que vous pouvez configurer les conteneurs J2EE EJB pour utiliser Hibernate 3.2. Aujourd’hui, EJB 3.0 est en train de regagner la confiance que lui avaient fait perdre les versions 1.0 et 2.0, principalement parce que 3.0 supporte le développement POJO. Malheureusement, la plupart des sites i5 ne pourront pas utiliser EJB 3.0 parce qu’il exige la présence de WAS 6.1. Hibernate est, de loin, le leader des ORM. En mars 2007, la version 3 d’Hibernate a été téléchargée 1,3 millions de fois, et on peut trouver plus d’une dizaine de livres, des centaines d’articles et une grande variété de formations. Hibernate, OJB et la plupart des autres frameworks ORM génèrent dynamiquement des instructions SQL select, insert, update et delete – à l’exception notable de iBatis. L’autogénération de SQL par Hibernate et OJB leur permet de travailler avec une grande variété de bases de données sans modification importante de SQL. Cependant, si vous voulez assumer tout le SQL d’une application, iBatis est l’ORM qu’il vous faut. Avec iBatis, vous écrivez le SQL vous-mêmes (figure 4).

L’exigence iBatis pour SQL est une arme à double tranchant : elle vous permet de supporter des bases de données héritées, de faire des appels de procédures stockées et de régler la performance avec SQL, mais elle demande davantage de travail de préparation et de manipulation du SQL lorsque votre base de données change. Je suis toujours parvenu à utiliser Hibernate avec d’anciennes bases de données, mais il est plus difficile de trouver comment utiliser Hibernate avec des bases de données bizarres qu’avec iBatis. En bref, Hibernate est bien plus configurable et doté de fonctions que iBatis, mais ce dernier peut s’apprendre plus rapidement.