|
|
|
|
|
|
Développons en Java v 1.60 | |
| Copyright (C) 1999-2011 Jean-Michel DOUDOUX |
 |
 |
 |
La quasi-totalité des applications de gestion traitent des données dans des volumes plus ou moins important. Dès que ce volume devient assez important, les données sont stockées dans une base de données.
Il existe plusieurs types de base de données
La seconde catégorie est historiquement la plus répandue mais aussi une des moins compatible avec la programmation orienté objet.
Ce chapitre contient plusieurs sections :
La correspondance des données entre le modèle relationnel et le modèle objet doit faire face à plusieurs problèmes :
La persistance des objets en Java possède de surcroît quelques inconvénients supplémentaires :
La première approche pour faire une correspondance entre ces deux modèles a été d'utiliser l'API JDBC fournie en standard avec le JDK. Cependant cette approche possède plusieurs inconvénients majeurs :
Tous ces facteurs réduisent la productivité mais aussi les possibilités d'évolutions et de maintenance. De plus, une grande partie de ce travail peut être automatisé.
Face à ce constat, différentes solutions sont apparues :
Le mapping Objet/Relationnel (mapping O/R) consiste à réaliser la correspondance entre le modèle de données relationnel et le modèle objets de façon la plus facile possible.
Un outil de mappping O/R doit cependant proposer un certain nombre de fonctionnalités parmi lesquelles :
Les solutions de mapping sont donc riches en fonctionnalités ce qui peut rendre leur mise en oeuvre plus ou moins complexe. Cette complexité est cependant différente d'un développement de toute pièce avec JDBC.
Les solutions de mapping O/R permettent de réduire la quantité de code à produire mais impliquent une partie configuration (généralement sous la forme d'un ou plusieurs fichiers XML ou d'annotations pour les solutions reposant sur Java 5).
Depuis quelques années, les principales solutions mettent en oeuvre des POJO (Plain Old Java Object).
Comme pour tout choix d'une solution, des critères standards doivent entrer en ligne de compte (prix, complexité de prise en main, performance, maturité, pérennité, support, ...)
Dans le cas d'une solution de mapping O/R, il faut aussi prendre en compte des critères plus spécifiques à ce type de technologie.
La solution doit proposer des fonctionnalités de base :
La prise en compte des performances et des optimisations proposées par la solution est très importante :
Il est aussi nécessaire de tenir compte des outils proposés par la solution pour faciliter sa mise en oeuvre. Ces outils peuvent par exemple :
Certaines fonctionnalités avancées peuvent être utiles voire requises en fonction des besoins :
De nombreuses difficultés peuvent survenir lors de la mise en oeuvre d'un outil de mapping O/R
Dans une architecture en couche, il est important de prévoir une couche dédiée aux accès aux données.
Il est assez fréquent dans cette couche de parler de la notion de CRUD qui représentent un ensemble des 4 opérations de bases réalisable sur une données.
Il est aussi de bon usage de mettre en oeuvre le design pattern DAO (Data Access Object) proposé par Sun.
La partie du code responsable de l'accès aux données dans une application multi niveaux doit être encapsulée dans une couche dédiée aux interactions avec la base de données de l'architecture généralement appelée couche de persistance. Celle-ci permet notamment :
La couche métier qui va utiliser la couche de persistance reste indépendante du code dédié à l'accès à la base de données. Ainsi la couche métier ne contient aucune requête SQL, ni code de connexion ou d'accès à la base de données. La couche métier utilise les classes de la couche métier qui encapsulent ces traitements. Ainsi la couche métier manipule uniquement des objets pour les accès à la base de données.
Le choix des API ou des outils dépends du contexte : certaines solutions ne sont utilisables qu'avec la plate-forme Enterprise Edition (exemple : les EJB) ou sont utilisables indifféremment avec les plates-formes Standard et Enterprise Edition.
L'utilisation d'une API standard permet de garantir la pérennité et de choisir l'implémentation à mettre en oeuvre.
Les solutions open source et commerciales ont les avantages et inconvénients inhérents à leur typologie respective.
L'acronyme CRUD (Create, Read, Update and Delete) désigne les quatre opérations réalisables sur des données (création, lecture, mise à jour et suppression).
| Exemple : une interface qui propose des opérations de type CRUD pour un objet de type Entite |
public interface EntiteCrud {
public Entite obtenir(Integer id);
public void creer(Entite entite);
public void modifier(Entite entite);
public Collection obtenirTous();
public void supprimer(Entite entite);
} |
DAO est l'acronyme de Data Access Object. C'est un modèle de conception qui propose de découpler l'accès à une source de données.
L'accès aux données dépend fortement de la source de données. Par exemple, l'utilisation d'une base de données est spécifique pour chaque fournisseur. Même si SQL et JDBC assurent une partie de l'indépendance vis-à-vis de la base de données utilisées, certaines contraintes imposent une mise à en oeuvre spécifique de certaines fonctionnalités.
Par exemple, la gestion des champs de type identifiants est proposée selon diverses formes par les bases de données : champ auto-incrémenté, identity, séquence, ...
Le motif de conception DAO proposé dans le blue print de Sun propose de séparer les traitements d'accès physique à une source de données de leur utilisation dans les objets métiers. Cette séparation permet de modifier une source de données sans avoir à modifier les traitements qui l'utilise.
Le DAO peut aussi proposer un mécanisme pour rendre l'accès aux bases de données indépendant de la base de données utilisées et même rendre celle-ci paramétrable.
Les classes métier utilisent le DAO via son interface et sont donc indépendantes de son implémentation. Si cette implémentation change (par exemple un changement de base de données), seul l'implémentation du DAO est modifié mais les classes qui l'utilisent via son interface ne sont pas impactées.
Le DAO définit donc une interface qui va exposer les fonctionnalités utilisables. Ces fonctionnalités doivent être indépendantes de l'implémentation sous jacente. Par exemple, aucune méthode ne doit avoir de requêtes SQL en paramètre. Pour les même raisons, le DAO doit proposer sa propre hiérarchie d'exceptions.
Une implémentation concrète de cette interface doit être proposée. Cette implémentation peut être plus ou moins complexe en fonction de critères de simplicité ou de flexibilité.
Fréquemment les DAO ne mettent pas en oeuvre certaines fonctionnalités comme la mise en oeuvre d'un cache ou la gestion des accès concurrents.
Différentes solutions peuvent être utilisées pour la persistance des objets en Java :
La plupart de ces solutions offre de surcroît un choix plus ou moins important d'implémentations.
Les différentes évolutions de Java ont apportées plusieurs solutions pour assurer la persistance des données vers une base de données.
JDBC est l'acronyme de Java DataBase Connectivity. C'est l'API standard pour permettre un accès à une base de données. Son but est de permettre de coder des accès à une base de données en laissant le code le plus indépendant de la base de données utilisée.
C'est une spécification qui définit des interfaces pour se connecter et interagir avec la base de données (exécution de requêtes ou de procédures stockées, parcourt des résultats des requêtes de sélection, ...)
L'implémentation de ces spécifications est fournis par des tiers, et en particulier les fournisseurs de base de données, sous la forme de Driver.
La mise en oeuvre de JDBC est détaillée dans le chapitre JDBC
JDO est l'acronyme de Java Data Object : le but de cet API est de rendre transparent la persistance d'un objet. Il repose sur l'enrichissement de byte-code à la compilation.
Cette API a été spécifiée sous la JSR-012
Il existe plusieurs implémentations dont :
La mise en oeuvre de JDO est détaillée dans le chapitre JDO
La version 2 de JDO a été diffusée en mars 2006.
Il existe de plusieurs implémentations dont :
Les EJB (Enterprise Java Bean) proposent des beans de type Entités pour assurer la persistance des objets.
Les EJB de type Entité peuvent être de deux types :
Les EJB bénéficient des services proposés par le conteneur cependant cela les rends dépendant de ce conteneur pour l'exécution : ils sont difficilement utilisables en dehors du conteneur (par exemple pour les tester).
Il existe de nombreuses implémentations puisque chaque serveur d'application certifié J2EE doit implémenter les EJB ce qui inclus entre autre JBoss de RedHat, JonAS, Geronimo d'Apache, GlassFish de Sun, Websphere d'IBM, Weblogic de BEA, ...
JPA (Java Persistence API) est issu des travaux de la JSR-220 concernant la version 3.0 des EJB : elle remplace d'ailleurs les EJB Entités version 2. C'est une synthèse standardisée des meilleurs outils du sujet (Hibernate, Toplink, ...)
L'API repose sur
JPA peut être utilisé avec Java EE dans un serveur d'application mais aussi avec Java SE (avec quelques fonctionnalités proposées par le conteneur en moins).
JPA est une spécification : il est nécessaire d'utiliser une implémentation pour la mettre en oeuvre. L'implémentation de référence est la partie open source d'Oracle Toplink : Toplink essential. La version 3.2 d'Hibernate implémente aussi JPA.
JPA ne peut être utilisé qu'avec des bases de données relationnelles.
La version 3.0 des EJB utilise JPA pour la persistance des données.
La mise en oeuvre de JPA est détaillée dans le chapitre JPA
Pour palier à certaines faiblesses des API standards, la communauté open source a développé de nombreux frameworks concernant la persistance de données dont le plus utilisé est Hibernate. Cette section va rapidement présentés quelques uns d'entre eux.
Le site officiel du projet est à l'url : http://ibatis.apache.org/
Hibernate est le framework open source de mapping O/R le plus populaire. Cette popularité est liée à la richesse des fonctionnalités proposées et à ses performances.
Hibernate propose son propre langage d'interrogation HQL et a largement inspiré les concepteurs de l'API JPA. Hibernate est un projet open source de mapping O/R qui fait référence en la matière car il possède plusieurs avantages :
Le site officiel du projet est à l'url : http://www.hibernate.org/
L'utilisation d'Hibernate est détaillée dans le chapitre Hibernate
Castor permet de mapper des données relationnelles ou XML avec des objets Java.
Castor propose une solution riche mais qui n'implémente aucun standard.
Le site officiel du projet est à l'url : http://www.castor.org/
Torque est un framework initialement développé pour le projet Jakarta Turbine : il est développé depuis sous la forme d'un projet autonome.
Torque se compose d'un générateur qui va générer automatiquement les classes requises pour accéder à la base de données et d'un environnement d'exécution qui va permet la mise en oeuvre des classes générées.
Torque utilise un fichier XML contenant une description de la base de données pour générer des classes permettant des opérations sur la base de données grâce à des outils dédiés. Ces classes reposent sur un environnement d'exécution (runtime) fourni par Torque.
Le site officiel du projet est à l'url http://db.apache.org/torque/
TopLink a été racheté par Oracle et intégré dans ses solutions J2EE.
Le site officiel du produit est à l'url : http://www.oracle.com/technology/products/ias/toplink/index.html
La partie qui compose la base de TopLink est en open source.
Le site officiel du projet est à l'url http://db.apache.org/ojb/
Le site officiel du projet est à l'url http://cayenne.apache.org/
Cayenne est distribué avec un outil de modélisation nommé CayenneModeler.
L'utilisation de procédures stockées peut apporter des améliorations notamment en termes de performance de certains traitements.
Cependant, les procédures stockées possèdent plusieurs inconvénients :
|
|
|
|
|
|
Développons en Java v 1.60 |
|
|
| Copyright (C) 1999-2011 Jean-Michel DOUDOUX |