Editions ENI Livres | Vidéos | e-Formations
Les EJB Entity
Introduction
1. Définition
Un EJB Entity est une classe qui correspond à une table d’une base de données relationnelle. Une instance de cette classe correspond à une ligne de la table.
Les EJB Entity gèrent le mapping objet/relationnel.
2. Framework de persistance
Un "framework" est un ensemble d’outils et de librairies utiles au développement. En ce sens, JEE est un framework.
Certains frameworks, dits frameworks de persistance sont spécialisés dans le mapping objet/relationnel. Ils permettent de générer des classes Java à partir des tables de la base de données.
Voici quelques frameworks de persistance populaires : Toplink, Hibernate, EclipseLink…
3. Contexte de persistance
Pour effectuer le travail de mapping objet/relationnel, le conteneur d’EJB a besoin de connaître un certain nombre de renseignements qui constituent le contexte de persistance :
-
Les EJB Entity.
-
Quels sont les objets à utiliser ?
-
La source de données.
-
Quelle est la base de données à utiliser ?
-
En général, la source de données est un pool de connexions. C’est le pool qui connaît la base.
-
Le fournisseur de persistance.
-
Quel est le framework qui a généré les EJB ?
Le rôle du contexte de persistance est de :
-
Savoir où et comment stocker les informations.
-
S’assurer de l’unicité des instances de chaque...
Exemple complet : gestion des contacts
1. Objectif
Dans tous les projets de gestion des contacts précédents, nous utilisons les classes que nous avons développées dans notre travail sur le mapping objet/relationnel. Ces classes sont regroupées dans les packages suivants :
-
Les classes Contact, Secteur, Versement correspondent aux tables CONTACT, SECTEUR, VERSEMENT de la base de données. Ces classes sont dans le package metierMapping.
-
Les classes ContactDAO, SecteurDAO, VersementDAO gèrent les entrées/sorties dans la base pour chacune des classes de metierMapping. Ces classes sont dans le package daoJdbcMapping.
Nous allons remplacer toutes ces classes par des classes de type EJB Entity générées par un framework de persistance.
2. Généreration des classes EBJ Entity
Cette procédure compte plusieurs étapes automatisées dépendant de l’EDI utilisé. Quel que soit l’environnement, pour générer les classes correspondant aux tables, il faut :
-
préciser le pool de connexions lié à la base de données : jndiPoolGnmiMySql,
-
choisir les tables à "mapper" (pour lesquelles on va créer les classes EJB Entity) : CONTACT, SECTEUR, VERSEMENT,
-
choisir un nom de package pour ces classes : tables,
-
choisir le fournisseur de persistance (framework) : EclipseLink par exemple pour NetBeans 8,
-
choisir le type de chargement pour les objets en relation. L’option par défaut correspond en général au lazy loading. Avec cette option, les objets en relation avec un objet Contact (la liste de ses versements par exemple) ne seront chargés qu’au moment où on en a besoin.
Le framework génère des classes dont le code ressemble beaucoup à celui de nos classes Contact, Secteur et Versement.
Ce code est toutefois « encombré » d’annotations. Ce sont elles qui permettent au conteneur d’EJB de faire le lien avec la base de données. Ces annotations jouent le rôle des classes DAO.
Nous présentons ci-après la classe générée et le rôle des principales annotations.
a. Classe Contact générée
package tables;
. . .
La déclaration de la classe est précédée...
Travail pratique : Projet GestionContactEJBEntite
1. Objectifs
-
Utiliser l’EJB Session MappingEntite pour accéder à la base de données.
-
Architecture de l’application :
2. Sujet
a. À réaliser
L’application reprend l’application GestionContactEJB du chapitre sur les EJB Session.
-
Adapter les programmes ServletControleur, TraitementAccueil et TraitementEnregModif.
-
Modifier légèrement les JSP : les classes Contact, Secteur, Versement proviennent désormais du package tables et non du package metierMapping. Modifier quelques « import » des JSP…
b. Diagramme de séquence
3. GestionContactEJBEntite : proposition de correction
a. ServletControleur
Par rapport au projet GestionContactEJB, peu de changement dans la classe ServletControleur. Seul l’objet distant change : c’est un objet de type MappingEntiteRemote :
. . .
import objetDistant.MappingEntiteRemote;
public class ServletControleur extends HttpServlet
{
private TraitementAccueil traitementAccueil;
private TraitementModif traitementModif;
private MappingEntiteRemote mapping;
public void init()
{
try
{
. . .
mapping = (MappingEntiteRemote) ctx.lookup("jndiMappingEntiteMySql");
traitementAccueil = new TraitementAccueil(mapping);
traitementModif = new TraitementModif(mapping);
}
. . .
b. Classe TraitementAccueil
La classe utilise l’objet distant d’interface MappingEntiteRemote. Elle utilise les classes EJB Contact et Secteur du package tables :
. . .
import objetDistant.MappingEntiteRemote;
import tables.Contact;
import tables.Secteur;
. . . Dans cette application, les annotations des classes Contact et Secteur ne servent à rien.
La méthode traitementListe() appelle les méthodes de l’objet distant :
public class TraitementAccueil
{
private MappingEntiteRemote mapping;
....
