|
Le pattern: Entity Façade |
|
|
|
Conception -
Patterns
|
|
Ecrit par Kamal AOUDA
|
|
28-12-2005 |
|
La création d
La création d’autant
d’entity beans qu’il y a de tables dans une base de données est une pratique
courante qui est cautionnée par plusieurs outils de mapping entre les modèles
objets et les modèles relationnels de données. Cette pratique est pénalisante
pour les ressources parce qu’il faut associer une instance du bean à chaque
ligne de la table, stocker les champs (colonnes) dans les propriétés de cette
instance et gérer les relations entre les tables comme des relations entre les
beans. Le pattern Entity Façade permet de résoudre ce problème en compilant les
données issues de plusieurs tables dans un nombre restreint d’entity beans
composites.
Outre la diminution de la quantité de mémoire consommée, le pattern réduit le
trafic sur le réseau, limite le nombre de messages échangés entre les différents
beans et diminue le nombre d’appels à la base de données.
Pour étayer les affirmations énumérées ci-dessus nous nous permettons de
reproduire un exemple donné dans le livre J2EE design patterns. La figure 42
représente le modèle relationnel d’une clinique médicale. Dans ce modèle
normalisé un patient peut avoir une ou plusieurs adresses. De même une à
plusieurs notes peuvent être associées aux différentes visites qu’il effectue.
Nous supposons que le client effectue en moyenne 4 visites par an, que 10 notes
sont en moyenne annotées à son dossier et que la clinique reçoit en moyenne
10.000 clients par an.
Si on crée autant d’EJB qu’il y a de tables dans le modèle relationnel, il
faudra créer 40 instances de l’entity bean pour récupérer les notes associées au
dossier de chaque client à partir de la base de données (soit 400.000 instances
pour gérer tout le portefeuille de clients). Ces instanciations pléthoriques
influent non seulement sur la mémoire consommée mais également sur le trafic et
le temps nécessaire pour générer les vues.
Figure 42: Modèle
relationnel de données d’une clinique médicale [187]

Pour remédier à ces
problèmes le pattern Entity Facade propose de ne convertir en entity bean que
les tables parent PATIENT et VISIT. Les autres tables sont versées dans des
collections et/ou de simples objets Java au moment du chargement du
HospitalVisit et du Patient Beans (cf. figure 43). Ce design rend difficile la
gestion de la persistance au niveau du conteneur (CMP) mais il permet des
économies substantielles sur la mémoire, le temps de réponse et le trafic.
Figure 43: Pattern
Entity Façade [188]

Notes de bas de
page
[187] Source: William
Crawford, Jonathan Kaplan, J2EE Design Patterns, O'Reilly, September 2003, ISBN:
0-596-00427-3, 368
[188] Source: Idem
|
|
Dernière mise à jour : ( 28-12-2005 )
|