Introduction
Ces instructions portent sur l'identification de beans entity. Des conseils supplémentaires sur les beans entity
figurent dans Instructions : Bean entity. Des conseils généraux sur les EJB sont disponibles dans
Instructions : Enterprise JavaBean (EJB)
Identification des beans entity
Les classes d'analyse d'entité (reportez-vous à Produit : Classe d'analyse) constituent souvent des candidats
appropriés pour les beans entity, ces derniers étant adaptés aux données persistantes. Les beans entity correspondent
aux entités métier qui contiennent l'état persistant. Ils offrent des services implémentant la logique spécifique aux
entités métier. Une autre caractéristique des beans entity réside dans le fait qu'ils peuvent offrir simultanément
leurs services à plusieurs clients. Le conteneur d'EJB traite la coordination entre ces clients, ainsi que leurs
transactions.
Les beans entity sont utilisés pour fournir la persistance, mais peuvent également encapsuler la logique métier. Il est
en règle générale conseillé qu'un bean entity contienne uniquement la logique métier relative aux données conservées
par le bean entity et tout objet de données qui en dépend. Il est en règle générale également recommandé que la logique
de bean inter-entity soit extraite vers des beans session, afin de minimiser le couplage entre beans entity.
Modélisation des beans entity
Reportez-vous à Instructions : Identification d'Enterprise JavaBeans (EJB).
Granularité
La granularité fait référence à la taille des données représentées par l'EJB entity. La granularité appropriée peut
dépendre de la version de la spécification d'EJB en cours d'utilisation.
Avant EJB 2.0, il était recommandé que les EJB entity comportent toujours une granularité élevée (ils représentaient
alors généralement de grands groupes de données formés à partir de plusieurs tables de base de données). Ceci était dû
au fait que des temps système significatifs étaient associés à chaque EJB entity (en particulier pour les temps système
liés à la possibilité de transfert). Il est conseillé que les postes d'une facture ou les cellules d'une feuille de
calcul, par exemple, qui présentent une granularité trop faible, ne soient pas sujet à un trop grand nombre de
tentatives d'accès via un réseau. A l'inverse, les groupes logiques d'entrées d'une facture ou un sous-ensemble de
cellules d'une feuille de calcul peu(ven)t être modélisé(s) comme un EJB entity, si une logique métier supplémentaire
est requise pour les données.
Avec EJB 2.0, les considérations relatives à la granularité diffèrent quelque peu (l'introduction d'interfaces locales
réduit sensiblement ces temps système et permet la modélisation d'objets de plus faible granularité comme des EJB). La
rubrique Concept : Présentation de Java 2 Platform Enterprise Edition (J2EE) décrit les
interfaces locales et distantes. Le temps système d'une interface locale n'est pas associé à une interface distante, ce
qui permet une interaction plus efficace entre les beans fortement couplés. Les interfaces locales sont
particulièrement utiles pour les entités de faible granularité employées pour former une entité de plus grande taille,
responsable de la création et la destruction des différentes parties. Les clients recourent à l'interface distante de
l'entité de plus grande taille qui, à son tour, utilise les interfaces locales pour interagir avec les différentes
parties.
Si un bean entity présente une relation de composition avec une autre classe, vous pouvez toutefois choisir de
modéliser cette dernière comme une classe Java classique et non comme un bean entity. Lorsque la persistance gérée par
conteneur est employée, une classe Java de ce type est alors appelée "classe de valeur dépendante". Il est plus simple
et plus rapide de développer et de tester les classes de valeur dépendantes que les beans entity. L'utilisation de
classes de valeur dépendantes représente une solution convenable et suppose que les fonctions des bean entity ne sont
pas requises par la classe composée. Quelques limites des classes de valeur dépendantes sont indiquées ci-dessous :
-
Elles ne peuvent pas contenir de référence aux bean entity.
-
Elles sont "obtenues" et "définies" par une valeur, ce qui n'est pas transparent en termes de performances, mais
active l'accès à partir de l'interface distante.
Encapsulation
Etudiez la possibilité d'encapsuler un ensemble de beans entity liés avec une façade de bean session, afin de fournir
une interface logique permettant de manipuler des entités métier correspondant aux EJB entity. Reportez-vous à Instructions : Identification de beans session.
Une approche analogue consiste à considérer l'encapsulation par un bean entity d'un ensemble d'autres beans entity
locaux, dépendants en règle générale. Le bean entity "principal" permet aux clients distants d'accéder à l'ensemble des
données. La spécification Core J2EE Patterns - Composite Entity Pattern (Patterns J2EE centraux - Pattern d'entité
composite) ([ALU01] étudie cette alternative ; elle recommande toutefois le recours à une façade
de bean session comme méthode de gestion des relations entre beans entity.
|