La persistance des données avec JDBC et JPA

Introduction

L’utilisation de données dans une application web est incontournable et les bases de données relationnelles sont largement utilisées. Comme différents SGBDR (système de gestion de bases de données relationnelles) sont disponibles, Oracle (Sun initialement) a décrit au travers d’une spécification la manière dont une application doit communiquer avec une base de données relationnelle. Il s’agit de la JSR 221 décrivant la technologie JDBC (Java DataBase Connectivity) dans sa version 4.2. La section suivante, La spécification JDBC, décrit les éléments indispensables dans l’utilisation de cette technologie.

Une grande part du travail à réaliser par le développeur dans l’utilisation d’une base de données est de faire le lien entre les objets manipulés dans le programme Java et les données stockées dans les tables. Ainsi des frameworks sont nés pour simplifier cette tâche tout en s’appuyant sur l’API JDBC. Ces frameworks portent le nom d’ORM (Object Relational Mapping) car ils ont pour objectif de faire l’association (Mapping) entre les objets (Object) et les données stockées dans une base de données relationnelle (Relational). Le framework le plus connu est Hibernate. Face à l’émergence de ces frameworks, Oracle...

La spécification JDBC

1. Description

L’API JDBC fait partie de la plateforme Java SE. En effet, l’accès à une base de données n’est pas réservé aux applications déployées sur la plateforme Java EE.

L’API JDBC permet d’écrire un programme Java indépendamment du SGBDR sous-jacent. Dans la documentation officielle, il est écrit "Write Once, Run Anywhere". Ceci signifie que votre programme peut s’exécuter avec n’importe quel SGBDR sans changer une ligne de code. Il faudra, cependant, mettre un bémol, si vous souhaitez utiliser des fonctionnalités avancées d’un SGBDR en particulier.

L’API JDBC est composée d’interfaces et de classes utilitaires. Pour pouvoir communiquer avec une base de données, il est donc nécessaire d’avoir une implémentation de ces interfaces. Cette implémentation est fournie par des bibliothèques externes que l’on appelle pilotes ou drivers. Ces pilotes sont généralement mis à disposition par les sociétés qui développent les SGBDR.

2. Les différents types de pilotes

Il existe différents types de pilotes JDBC. Ils sont au nombre de quatre :

Les pilotes de type 1 (pilotes JDBC-ODBC) : les pilotes de type 1 sont des pilotes ne communiquant pas directement avec le SGBDR mais passant par l’intermédiaire d’un pilote ODBC (Open DataBase Connectivity). Ils jouent donc le rôle de passerelle vers la technologie ODBC (JDBC-ODBC Bridge). L’intérêt de ce type de pilote est le fait qu’il peut être utilisé avec différents SGBDR. Il est nécessaire qu’un pilote ODBC soit installé sur la machine cliente. Les limites se situent principalement au niveau des performances car on passe par une couche logicielle supplémentaire. Les fonctionnalités disponibles sont aussi limitées par les fonctionnalités mises à disposition par le pilote ODBC. Ce type de pilote n’est à utiliser que s’il n’existe pas d’autre pilote disponible.
Les pilotes de type 2 (pilotes natifs) : les pilotes de type 2 sont des pilotes ne communiquant pas directement avec le SGBDR mais passant par l’intermédiaire de librairies natives (spécifiques...

La spécification JPA

1. Description

L’API JPA (Jakarta Persistence) fait partie de la plateforme Jakarta EE. Elle permet de simplifier l’accès aux données en mettant à disposition des fonctionnalités avancées. L’API JPA s’appuie sur l’API JDBC pour communiquer avec les bases de données. Il est possible de considérer l’API JPA comme une surcouche à l’API JDBC. Les principales fonctionnalités que l’on peut déjà citer sont :

L’automatisation de l’association (mappage) entre les données stockées dans les colonnes des tables et les variables membres des classes Java.
La mise au point automatique des requêtes SQL nécessaires pour manipuler les données dans le programme Java.
La standardisation de l’architecture mise en place pour interroger une base de données.

La spécification JPA est un ORM. Elle permet de rendre plus ou moins transparent le pont entre le monde objet (écrit en Java) et le monde relationnel.

La version actuelle JPA 3.0 est décrite dans la spécification consultable à l’adresse suivante : https://jakarta.ee/specifications/persistence/3.0/jakarta-persistence-spec-3.0.pdf. Le chapitre a pour objectif de présenter les éléments essentiels pour bien démarrer un projet avec JPA. Les spécificités de la version 3.0 ne seront donc pas abordées.

2. Les principales implémentations

JPA n’est "qu’une" spécification. Pour utiliser JPA dans un projet, il faut choisir une implémentation de cette spécification. Il en existe plusieurs. Certaines sont plus populaires que d’autres.

Voici les principales implémentations :

EclipseLink est l’implémentation de référence depuis JPA 2.0. Elle est maintenue par la fondation Eclipse. Pour plus d’informations, consultez le site à l’adresse suivante : http://www.eclipse.org/eclipselink/
Hibernate est l’ORM le plus utilisé dans le monde Java. Il a été créé avant la spécification JPA mais il l’a implémentée dès qu’elle est apparue. C’est l’implémentation utilisée pour ce chapitre. Cette implémentation...

Conclusion

Ce chapitre a permis de faire un tour d’horizon des deux API permettant d’accéder aux données dans une application Java EE. La montée en compétence sur l’API JDBC est rapide. La mise en œuvre est simple et adaptée à de petits projets. L’API JPA demande plus de temps et d’efforts pour monter en compétence. La mise en œuvre est alors relativement simple et adaptée à de petits comme de grands projets.