accueilLogicielsDéveloppement et Qualité LogicielsÉcosystème Java
 

Persistance Java avec JPA - Concepts


Java et la persistance des objets métiers

La programmation orientée objets est aujourd’hui un standard. La persistance des objets est un point critique, dont dépend la performance et la disponibilité des informations de tout projet Java. C’est pourquoi il est important de séparer les responsabilités d’accès aux données sérialisées des interfaces homme-machine.
La couche métier ne doit contenir que la logique métier, c’est à dire propre à l’objet qu’elle représente.
La couche DAO (Data Access Objects) a pour but de transformer les objets métiers en données sérialisées et inversement.
La couche UI (User Interface) regroupe tout ce qui a trait à la présentation des données et aux interactions avec l’utilisateur, en appelant des traitements mis à disposition sous forme de méthode par les objets métier.

JPEG - 46.6 ko
Architecture 3-Tiers

La sérialisation peut être assurée sur différents types de support (mémoire, fichiers, bases de données…)

Il est possible de développer ses propres outils avec les classes de sérialisation du JDK, mais c’est couteux à mettre en œuvre et à faire évoluer avec les versions du JDK. De plus ces classes ne sont exécutables qu’en local.

L’utilisation de bases de données permet de répondre à ces problématiques. Bien que les bases de données orientées objet telles ObjectStore et DB4O et les bases de données NoSQL soient l’outil de sérialisation idéal, ce sont les moteurs de bases de données relationnelles qui dominent le marché. Elles n’ont pas réussi à s’imposer face aux géants des bases de données relationnelles notamment à cause de la reprise de bases de données relationnelles déjà présentes dans les systèmes d’information des entreprises.

Les développements basés sur l’utilisation directe des interfaces JDBC assurent un pont de bas niveau pour communiquer avec une base de données relationnelle en SQL.

JPEG - 27.3 ko
Architecture 3-Tiers avec JDBC

Dans ce cas, la couche DAO va faire correspondre de manière bijective

  • une table (appelée aussi relation) à une liste d’objets
  • une ligne d’une table (appelée aussi tuple) à un objet
  • un champs de base de données à un attribut d’objet
  • une valeur d’un champs à une valeur d’attribut d’un objet Des modifications du modèle de données ont des répercussions sur les requêtes aux bases, ce qui implique de faire évoluer individuellement les appels jdbc. La maintenance est de ce fait couteuse.

Pour pallier à cette problématique et faciliter l’écriture de la couche DAO, il faut s’affranchir de la forme brute des données. La communauté Java a donc fait naître des frameworks de DAO, tels que Hibernate, Toplink, EclipseLink, Oracle BC4J... Ces ORM (Object Relational Mapping) permettent de se libérer d’une partie de la gestion des accès aux données. Le développeur de la couche DAO ne voit plus la couche JDBC ni les tables de la base de données. Il ne voit que l’image objet de la base de données fournie par la couche ORM.

JPEG - 23.3 ko
Couche DAO avec l’ORM Hibernate

Comme ils ne reposent pas sur des standards Java, le choix de l’ORM n’est pas sans conséquences sur le code utilisé pour transférer une donnée métier dans la base de données. Il n’est en effet pas si aisé de passer de Hibernate à TopLink par exemple.

Fort du succès des ORM, Sun décide de créer un standard pour l’utilisation de la couche ORM dans Java 5 : JPA (Java Persistence API). La couche DAO dialogue avec la spécification JPA qui est un ensemble d’interface du package javax.persistence. Quelque soit le produit qui implémente celle-ci, l’interface JPA utilisée dans la couche DAO reste la même. La couche DAO a ainsi été simplifiée et ne dépend plus du choix du fournisseur d’ORM ni du fournisseur de base de données puisqu’il est également possible d’utiliser certaines bases NoSQL telles que ObjectDB.

JPEG - 27.8 ko
Couche DAO avec JPA

Bien avant JPA, Sun avait proposé JDO (Java Data Object), un standard pour assurer la persistance des objets Java dans tout type de système de gestion de ressources (bases de données relationnelles ou objets, fichiers XML, ...). Il existe même des implémentations pour des sources mainframe, JMS (Java Messaging Service) et webservices. En comparant JDO et JPA on peut s’apercevoir que JPA est un sous-ensemble de JDO. Et pourtant JDO n’a pas été un succès et finalement il existe plus d’implémentations JPA. Donc pour des raisons d’évolutivité et de maintenabilité, il vaut mieux privilégier l’utilisation de JPA.

 

Guillaume HARRY
Envoyer un courriel


ARESU
Direction des Systèmes d'Information du CNRS

358 rue P.-G. de Gennes
31676 LABEGE Cedex

Bâtiment 1,
1 Place Aristide Briand
92195 MEUDON Cedex



 

 

Direction des Systèmes d'Information

Pôle ARESU

Accueil Imprimer Plan du site Credits