|
EJB 2 - Les Entreprise Java Bean (JavaBeans)
3.4.Qu’est ce qu’un
Entity Bean
Un entity bean représente un
objet métier dans un mécanisme de stockage persistant.
Voici quelques exemples d’objets métiers : des
clients, des ordres d’achats, des produits. Dans le serveur
applicatif, le mécanisme de stockage persistant est une base
de données relationnelle. Typiquement, chaque entity bean
correspond à une table dans une base de données
relationnelle, et chaque exemple de bean correspond à une
entrée dans cette table.
3.4.1.Différences entre
Entity Beans et Session Beans
Les entity beans diffèrent des
session beans de plusieurs manières. Les entity beans sont
persistants, permettent des accès partagés, possèdent
des clés primaires et peuvent participer aux relations avec
d’autres entity beans.
Persistance
Comme l'état d'un entity bean
est sauvegardé sur un support de stockage, il est persistant.
La persistance signifie que l'état de l’entity bean
existe au delà de la vie de l'application ou du processus du
serveur applicatif. Les données dans une base de données
sont persistantes du fait qu'elles existent toujours, même
après l’arrêt du serveur de base de données
ou des applications qui les utilisent.
Il existe deux types de persistance
pour les entity bean : gérée par le bean (bean-managed)
et gérée par le conteneur (container-managed). Pour la
persistance bean-manged (BMP), le code de l’entity bean doit
contenir les appels qui accèdent à la base de données.
Si votre bean a une persistance container-managed (CMP), le conteneur
d'EJB génère automatiquement les accès
nécessaires à la base de données. Le code que
vous écrivez pour l'entity bean n'inclut pas ces appels.
Accès
partagé
Les entity beans peuvent être
partagés par de multiples clients. Comme les clients
pourraient vouloir changer les mêmes données, il est
important que les entity beans travaillent à l’intérieur
de transactions. Typiquement, le conteneur d’EJB fournit la
gestion de transaction. Dans ce cas, vous spécifiez les
attributs de la transaction dans le descripteur de déploiement
du bean. Vous n’avez pas besoin de coder les limites de la
transaction dans le bean ; le conteneur définit les
limites pour vous.
Clé
primaire
Chaque entity bean possède un identifiant unique. Un entity
bean client, par exemple, pourrait être identifié par un
numéro de client. L’identifiant unique, ou clé
primaire, permet au client de localiser un entity bean
particulier.
Relations
Comme une table dans une base de données relationnelle, un
entity bean peut être lié à d’autres entity
beans. Par exemple, dans une application de gestion d’établissement
scolaire, StudentBean et CourseBean devraient être reliés
car les étudiants suivent des cours.
Vous implémentez les relations différemment suivant si
la persistance de l’entity bean est gérée par le
bean ou par le conteneur. Avec la bean-manged persistence (BMP),
le code que vous écrivez implémente les relations. Mais
avec la container-managed persistence (CMP), le conteneur
d’EJB prend en charge les relations pour vous. Pour cette
raison, les relations entre des entity beans dont la persistance est
gérée par le conteneur sont souvent appelées
container-managed relationships (CMR : relations gérées
par le conteneur).
3.4.2.Container-Managed Persistence
Le terme container-managed persistence (CMP) signifie que le
conteneur d’EJB s’occupe de tous les accès à
la base de données, requis par l’entity bean. Le code du
bean ne contient aucun accès à la base (SQL). Le
résultat est que le code du bean n’est pas spécifique
à une base de données. Du fait de cette flexibilité,
même si vous redéployer le même entity bean sur un
autre serveur J2EE utilisant une base de données différente,
vous n’avez pas à modifier ou recompiler le code du
bean. En bref, vos entity beans sont plus portables si vous utilisez
la persistance container-managed que s'ils utilisaient la persistance
bean-managed.
Pour générer les accès à la base, le
conteneur nécessite des informations que vous fournissez dans
le schéma abstrait de l’entity bean.
Schéma
abstrait
Faisant partie du descripteur de déploiement de l’entity
bean, l’abstract schema définit les champs
persistants et les relations du bean. Le terme abstrait distingue ce
schéma du schéma physique de la base de données.
Dans une base de données relationnelle, le schéma
physique correspond à la structure des tables et colonnes.
Vous spécifiez le nom d’un schéma abstrait dans
le descripteur de déploiement. Ce nom est référencé
par les requêtes écrites dans l’Enterprise
JavaBeans Query Language (EJB QL). Pour un entity bean dont la
persistance est gérée par le conteneur, vous devez
définir une requête EJB QL pour chaque méthode de
recherche (excepté findByPrimaryKey). La requête EJB QL
détermine la requête qui est exécutée par
le conteneur d’EJB quand la méthode de recherche est
appelée.
Vous trouverez cela peut-être utile de faire un croquis du
schéma abstrait avant d’écrire du code. Le schéma
1-1 représente un schéma abstrait simple qui décrit
les relations entre trois entity beans. Ces relations sont traitées
un peu plus loin.
Schéma 1-1 : Une vue haut niveau d’un schéma
abstrait
Champs Persistants
Les champs persistants d’un entity bean sont sauvegardés
dans l’espace de stockage. Ces champs constituent l'état
du bean. Au moment de l'exécution, le conteneur d’EJB
synchronise automatiquement cet état avec la base de données.
Lors du déploiement, le conteneur mappe typiquement l’entity
bean à une table de la base et mappe les champs persistants
aux colonnes de la table.
Un entity bean ClientEJB, par exemple, pourrait avoir des champs
persistants comme prenom, nom, tel et email. Dans le cas de la
persistance container-managed persistence (CMP) ces champs sont
virtuels. Vous les déclarez dans le schéma
abstrait, mais vous ne les codez pas comme des variables d’instances
dans la classe de l’entity bean. Au lieu de cela, les champs
persistants sont identifiés dans le code par des méthodes
d’accès (getters et setters).
Champs Relationnel
Un champ relationnel est comme une clé étrangère
dans une table de base de données : il identifie une
relation à un bean. Comme un champ persistant, un champ
relationnel est virtuel et est défini dans la classe du bean
avec des méthodes d’accès. Mais contrairement à
un champ persistant, un champ relationnel ne représente pas
l’état du bean. Les champs relationnels seront traités
plus en détail au point suivant.
Type des
relations gérées par le conteneur (CMR)
Il y a quatre types de relation :
-
One-to-one (un-un) : Chaque instance d’entity
bean est reliée à un seule instance d’un autre
entity bean.
-
One-to-many (un à n) : Une
instance d’entity bean peut-être reliée à
plusieurs instances de l’autre entity bean.
-
Many-to-one (n à un) : De multiples
instances d’un entity bean peuvent être reliées à
une unique instance d’un autre bean. Cette relation est
l’opposée de la relation précédente.
-
Many-to-many (n à m) : Les
instances de l’entity bean peuvent être reliées à
de multiples instances de l’autre bean.
Direction
des relations gérées par le conteneur
La direction d'une relation peut être bidirectionnelle ou
unidirectionnelle. Dans une relation bidirectionnelle, chaque entity
bean a un champ relationnel qui se rapporte à l'autre bean. À
travers le champ relationnel, le code d'un entity bean peut accéder
à son objet relatif. Si un entity bean a un champ relationnel,
alors on dit souvent qu'il "connaît" son objet
relatif. Par exemple, si OrderEJB sait quelles instances de
LineItemEJB il possède et si LineItemEJB sait à quel
OrderEJB il appartient, alors ils ont un rapport bidirectionnel.
Dans une relation unidirectionnelle, seul un entity bean possède
un champ relationnel qui référence un autre bean. Par
exemple, LineItemEJB aurait un champ relationnel qui identifie
ProductEJB, mais ProductEJB n’aurait pas de champ relationnel
pour LineItemEJB. En d’autres termes, LineItemEJB connaît
ProductEJB, mais ProductEJB ne sait pas à quelles instances de
LineItemEJB il réfère.
Les requêtes EJB QL naviguent souvent à travers des
relations. La direction d'une relation détermine si une
requête peut aller d'un bean vers un autre. Par exemple, une
requête peut aller de LineItemEJB à ProductEJB, mais ne
peut pas aller dans la direction opposée. Pour OrderEJB et
LineItemEJB, une requête pourrait aller dans les deux
directions, puisque ces deux beans ont une relation bidirectionnelle.
3.4.3.Quand utiliser les Entity
Beans
Vous devriez probablement utiliser un entity bean pour les conditions
suivantes :
-
Le bean représente une entité métier, pas une
procédure. Par exemple, CreditCardEJB serait un entity bean,
mais CreditCardVerifierEJB serait un session bean.
-
L’état du bean doit être persistant. Si
l’instance du bean est détruite ou si le serveur J2EE
est éteint, l’état du bean existe toujours dans
un stockage persistant (une base de données).
|
|
 |
