|
| |
| TUTORIEL JAVA |
 |
|
|
| La persistance Objet en Java : aborder EJB3 |
| Nouvelle version du standard Entreprise JavaBeans, EJB3 révise largement les techniques de EJB2. Approche de l'aspect persistance du standard, avec un exemple de code.
(19/07/2006) |
  |
 Les Entreprise JavaBeans (EJB) n'ont que peu de rapport avec les JavaBeans standards. Ces derniers sont des composants logiciels réutilisables, et pouvant être manipulés visuellement dans un outil de développement, selon leur spécification. Les EJB, de leur côté sont des composants serveur, qui prennent en charge la sécurité, la réplication, les transactions (lire notre article du 30/11/01) et, ce qui nous intéresse ici : la persistance.
Les EJB restent encore aujourd'hui un sujet difficile à aborder, du fait des évolutions assez radicales de leur spécification. La spécification EJB3, en cours de validation finale, cherche à revoir largement EJB2, jugé trop complexe pour les développements quotidiens. EJB2 elle-même a remis en cause nombre de fondations établies par la spécification initiale. En l'état actuel des choses, il faut donc choisir entre EJB2, bien établie côté outils, mais à terme remplacée par EJB3, ou cette dernière, dont le support outil commence à poindre.
La spécification de persistance avec EJB3 a été développée en parallèle à la spécification général de EJB3, et devrait à terme avoir son JSR propre.
Les travaux sur la persistance sont nombreux car c'est un sujet cher aux développeurs d'applications d'entreprise - au point que deux spécifications du JSR, EJB3 et JDO2, se battent pour avoir les bonnes grâces de la communauté en la matière. L'intérêt de la persistance est clair : pouvoir conserver des données temporaires de manière plus pérenne. La persistance se révèle obligatoire pour des applications où l'information doit transiter d'une application à une autre, ou être accessible (et inchangée) à n'importe quel moment.
Les méthodes sont nombreuses : au-delà des deux spécifications du JSR suscitées, Java peut également faire appel à la sérialisation pour stocker des objets sur un disque, ainsi qu'à des bases de données Objets, à des outils de correspondance Objet-donnée relationnelle (ORM, object-relational mapping), ou encore au framework Hibernate. L'intérêt de spécification comme EJB par rapport à la sérialisation simple est de ne pas avoir à gérer de manière explicite certaines problématiques comme les transactions, le multithreading ou la capacité de charge. Surtout, son avantage face aux autres solutions est d'offrir une API standardisée pour JSE et JEE.
Composition
Au sein de EJB3, la persistance Objet est supportée par six briques : un Domain Object Model (DOM, modèle Objet du domaine), des métadonnées, une API, un modèle de cycle de vie, un système de requêtes et un système de rappels (callbacks).
Un DOM est un modèle orienté Objet du domaine étudié. Ce terme est utilisé pour désigner les objets persistants ou les entités métier du domaine. La création de ce modèle requiert de connaître les objets de données utilisés et leurs attributs, et d'identifier les relations qui les lient.
Les métadonnées peuvent être de deux types : logique, la métadonnée décrit le DOM ; correspondance (mapping), la métadonnée décrit de quelle manière le DOM correspond au schéma de la base de données. Ces métadonnées sont écrites en XML, ou à l'aide des Annotations (introduites avec Java 5 - lire notre article du 03/03/05).
L'API de persistance est accessible en utilisant le paquetage Java javax.persistence. Celle-ci dispose de quelques classes et interfaces clés : EntityManager et Query sont les deux interfaces, utilisées respectivement pour gérer un jeu d'objets persistants, et pour découvrir les objets persistants qui remplissent certains critères. Parmi les classes, on trouve Persistence, Entity, EntityManagerFactory et EntityTransaction.
 |
Forum |
|
|
Réagissez
dans les forums
de JDN Développeurs
|
Les entités en persistance EJB représentent un jeu de données persistantes, correspondant généralement à des lignes de base de données, et offre les méthodes pour lire ou modifier ces données. Chaque entité dispose d'un identifiant unique (la clef primaire).
|
|
|
|
