Instructions: Identification de beans entity
Ces instructions portent sur l'identification et la modélisation de beans entity pour une application J2EE.
Relations
Description principale

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.