Préparation d'un projet

1. Fichier de mapping

Le fichier de mapping permet de configurer entièrement JPA et Hibernate par fichier XML.

Ce fichier décrit l’interaction entre chaque classe java utilisée pour modéliser les données avec les tables de la base de données. Ainsi, il y aura un élément XML par entité, dans lequel se trouvent la table concernée et le lien entre les attributs et les colonnes.

Voici un exemple de fichier de mapping :

<?xml version="1.0" encoding="UTF-8" ?> 
<entity-mappings xmlns="http://java.sun.com/xml/ns/persistence/orm" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm  
http://java.sun.com/xml/ns/persistence/orm_1_0.xsd" 
    version="1.0"> 
   ...

1. Création du fichier persistence.xml

Depuis NetBeans, la création de ce fichier se fait simplement par l’interface graphique de l’éditeur.

1. Classes définies par l’utilisateur

Pour faire une comparaison simplifiée avec les systèmes de gestion de base de données, ces classes peuvent être apparentées aux tables. C’est-à-dire que ce sont ces objets qui seront manipulés pour avoir accès aux différentes données stockées.

Ce sont les classes d’entités (Entity classes), les superclasses mappées (Mapped superclasses) et les classes intégrables (Embeddable classes). Elles servent de socle pour l’ORM.

@Entity 
public class Personne { 
  ... 
}
 

@Entity(name="NomDeLEntite")
 

1. Les champs temporaires

Comme vu précédemment, lorsque le mapping par annotation est utilisé, chaque propriété d’une entité est stockée en base de données.

Il est possible de vouloir qu’une donnée d’une entité ne soit pas stockée en base de données, comme les champs transients pour la sérialisation.

Ainsi, les champs static et/ou final ne sont pas mappés avec la base de données et ne sont donc pas stockés. Il est aussi possible d’utiliser le mot-clé transient comme pour la sérialisation ou encore d’utiliser l’annotation @Transient qui n’affecte que la persistance.

Par exemple, une entité représentant les quatre possibilités pour déclarer des champs temporaires :

@Entity 
public class EntitAvecChampTemporaire { 
    static int tmp1; // non persistant car static 
    final int tmp2 = 0;  // non persistant car final 
    transient int tmp3; // non persistant car transient 
    @Transient  
    int tmp4; // non persistant car @Transient 
}
 

2. Les champs persistables

Les champs persistables peuvent être séparés en deux catégories :

Dans cette partie, seuls les champs basiques sont abordés. Pour les relations entre les entités, il faut se reporter à la section Les relations de ce chapitre.

1. Clé primaire simple

Les clés primaires simples sont les clés les plus souvent rencontrées. C’est-à-dire que principalement, une entité a un champ unique qui sert de clé primaire, comme un identifiant technique qui est géré par l’application ou encore le numéro de Sécurité sociale pour une personne.

JPA permet de déclarer très simplement cette clé primaire, il suffit de rajouter l’attribut @Id au-dessus du champ concerné.

Par exemple, l’entité Personne, après ajout de cette déclaration, ressemble à :

@Entity 
public class Personne { 
 
    @Id 
    @Basic(optional = false) 
    private Integer id; 
 
    private String nom; 
 
    private String prenom; 
 
    @Column(name = "date_naissance") 
    @Temporal(TemporalType.DATE) 
    private...

1. Valeur fixe

La génération d’une valeur fixe dans un système de gestion de base de données se fait par l’ajout de la propriété Default sur une colonne. C’est-à-dire que si cette valeur n’est pas renseignée lors de la création d’une ligne, la valeur sera insérée automatiquement.

JPA n’a pas d’annotation permettant de gérer cette valeur et si le schéma de la base de données est généré par des scripts non gérés par JPA, cette propriété est à gérer normalement en l’initialisant avec la valeur voulue.

Par contre, si le schéma est généré via l’ORM, il est possible de contourner la limitation de JPA avec la propriété columnDefinition de l’annotation @Column.

Par exemple, pour rajouter une valeur par défaut égale à 10 sur une colonne, il suffit de rajouter :

@Column(columnDefinition="default '10'")
 

2. Valeur incrémentielle

Dans la plupart des cas, la gestion de l’identifiant unique est déléguée au système de...

1. Les relations 1-1 (OneToOne)

Les relations les plus simples entre deux entités sont les relations OneToOne. Comme vu à la section Classe intégrable, il est possible de stocker ces deux entités dans la même table, mais pour des raisons de conception il est possible de sauvegarder ces données dans deux tables différentes.

La représentation de cette relation se fait avec l’annotation @OneToOne.

Par exemple, une classe Personne ayant une relation OneToOne avec une classe PersonneDetail est déclarée de la façon suivante :

@Entity 
public class Personne { 
    @OneToOne  
    private PersonneDetail personneDetail; 
} 
  
@Entity 
public class PersonneDetail { 
    @OneToOne 
    private Personne personne; 
}
 

L’inconvénient de cette écriture est que la classe Personne connaît le lien avec la classe PersonneDetail et inversement. Ce qui veux dire que ces deux tables ont une clé étrangère l’une vers l’autre.

La solution pour ne plus avoir ces deux clés étrangères est de supprimer une des navigabilités.

Par exemple, la clé étrangère va être gardée au niveau de la table PersonneDetail. De ce fait le nouveau code source ressemble à l’exemple ci-dessous :

@Entity 
public class Personne { 
 
} 
  
@Entity 
public class PersonneDetail { 
    @OneToOne 
    private...

1. Lazy

Le chargement de type LAZY est le mode qui charge les données voulues au moment de leur première utilisation.

Pour une entité A ayant une relation ManyToMany avec une entité B, avec un fetch type LAZY, lors du chargement de l’entité A, les entités B en relation avec elle ne sont pas chargées automatiquement. Leur chargement ne se fait qu’au moment de l’appel de la liste.

Ce type de chargement a différents avantages :

Mais il a aussi ses inconvénients :

FetchType.LAZY est le comportement par défaut des relations ManyToMany et OneToMany. Pour simplifier, ce sont les annotations de relation de type "liste".

2. Eager

Le chargement de type EAGER est le mode...

1. Sérialisation

En soi, avec Hibernate, les entités n’ont pas besoin d’être sérialisables si l’application stocke directement les données en base. Par contre, lors d’une configuration un peu plus avancée de l’ORM avec certaines librairies de gestion de cache, l’entité doit être sérialisable. De ce fait, une bonne pratique lors de la création des entités est de les rendre sérialisables en implémentant l’interface java.io.Serializable.

Par exemple, en appliquant cette pratique à la classe Personne :

@Entity 
public class Personne implements Serializable { 
 
    private static final long serialVersionUID = 1L; 
 
    ... 
}
 

2. Equals et HashCode

En programmation orientée objet, il faut souvent redéfinir les méthodes equals() et hasCode() afin de pouvoir comparer les objets entre eux et/ou les stocker dans des listes. Par définition, les méthodes equals() et hashCode() ne doivent pas renvoyer de résultats différents tout au long de la durée de vie de l’objet. Ainsi, il y a trois façons principales d’utiliser...