Principes et conseils : Identification des beans d'entité
Rubriques
Introduction
Ces principes et conseils traitent principalement de l'identification des beans d'entité. Des conseils supplémentaires sur les beans d'entité sont donnés dans Principes et conseils : Beans d'entité. Des conseils généraux sur les EJB sont donnés dans Principes et conseils : Enterprise JavaBeans (EJB).
Identification des beans d'entité
Les classes d'analyse d'entité (voir Artefact : Classe d'analyse ) constituent souvent de bons candidats pour les beans d'entité, puisque ces derniers sont équipés pour les données persistantes. Les beans d'entité correspondent aux entités métier qui possèdent un état persistant. Ils fournissent les services qui implémentent la logique applicable spécifique aux entités. Les beans d'entité peuvent également fournir leurs services à plusieurs clients en même temps. Le conteneur EJB prend en charge la coordination de ces clients et de leur transactions.
Les beans d'entité servent à fournir de la persistance, mais peuvent également encapsuler la logique applicative. En général, un bean d'entité doit seulement contenir la logique applicative en rapport avec les données conservées par le bean d'entité et tout autre objet données dépendant. La logique des beans inter-entité doit normalement être extraite pour les beans de session afin de réduire au minimum le couplage entre les beans d'entité.
Modélisation des beans d'entité
Voir Principes et conseils : Identification des Enterprise JavaBeans (EJB).
Granularité
La granularité fait référence à la taille des données représentées par le bean d'entité. La granularité adéquate peut dépendre de la version de la spécification EJB utilisée.
Avant EJB 2.0, on recommandait toujours aux beans d'entité d'avoir une grosse granularité - représentant généralement des groupes importants de données de plusieurs tables de base de données. En effet, chaque entité EJB entraînait des surdébits importants, liés en particulier au fait d'être accessibles à distance. Par exemple les lignes articles d'une facture ou les cellules d'une feuille de calcul possèdent une granularité trop fine et il est déconseillé d'y accéder fréquemment dans un réseau. Au contraire, les groupes logiques des entrées d'une facture, ou un sous-ensemble de cellules dans une feuille de calcul peuvent être modélisés comme une entité EJB si une logique applicative supplémentaire s'avère nécessaire pour les données.
Cela est quelque peu différent dans EJB 2.0. L'introduction des interfaces locales réduit certains de ces surdébits et permet aux objets à fine granularité d'être modélisés comme des EJB. Les interfaces locales et distantes sont décrites dans Concepts :
Vue d'ensemble de J2EE : Enterprise JavaBeans. Une interface locale ne possède pas de surdébit associé à une interface distante, permettant aux beans fermement couplés d'interagir plus efficacement. Les interfaces locales sont particulièrement utiles pour les entités à fine granularité utilisées pour former un entité plus importante, cette dernière étant responsable de la création et de la destruction des composants. Les clients utilisent l'interface distante de l'entité plus importante, qui, à son tour, utilise les interfaces locales pour interagir avec ses composants.
Néanmoins, si un bean d'entité a une relation de composition avec une autre classe, vous pouvez alors décider de modéliser cette autre classe comme une classe Java ordinaire plutôt que comme un bean d'entité. Si vous utilisez la persistance gérée par conteneur, alors une telle classe Java est une "classe de valeur dépendante". Les classes de valeurs dépendantes sont moins difficiles et plus rapides à développer et à tester que les beans d'entité. Elles constituent de plus un choix approprié si la classe formée n'exige pas de caractéristiques de beans d'entité.
Les classes de valeurs dépendantes possèdent quelques limites :
- elles ne peuvent contenir de références de bean d'entité
- sont "obtenues (get) " et "définies (set) " par valeur, ce qui a un coût de performance mais permet l'accès depuis l'interface distante.
Encapsulation
Envisageons d'envelopper un ensemble de beans d'entité liés avec une façade bean de session pour fournir une interface logique pour manipuler les entités de gestion qui correspondent aux entités EJB. Voir Principes et conseils :
Identification des beans de session.
Considérons une approche similaire. Un bean d'entité encapsule un ensemble d'autre beans d'entité généralement locaux et dépendants. Les clients distants accèdent à toutes les données par le bean d'entité"principal". Modèles de base J2EE - Modèle d'entité composite ([ALU01] étudie cette alternative. Cependant, la façade bean de session est recommandée comme méthode plus simple pour gérer les relations des beans d'entité.
|