EcommerceDEV. Développement, optimisation et sécurisation des sites de commerce électronique.
arrowAccueil arrow Conception arrow Patterns arrow Le pattern: Entity Façade
Vendredi 25 juil 2008
Nom d'utilisateur     Mot de passe      Conserver       Mot de passe perdu ?  Inscription
Menu
Accueil
A propos du site
Carte du site
Moteur de recherche
Nouvelles
Contactez-nous
Evénements
Lettres de nouvelles
- - - - - - -
Analyse
Conception
Optimisation
Programmation
Sécurité
Produits/Services
déc 28 2005
Le pattern: Entity Façade Version imprimable Suggérer par mail
Appréciation des utilisateurs: / 0
FaibleMeilleur 
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 )
< Précédent   Suivant >
Moteur de recherche
Recommander ce site
Collaboration
Téléchargements
Derniers événements
Aucun événement
Sondages

Struts est-il adapté pour le développement des sites e-commerce ?

  
Blogs Ecommerce
Blog de capitaine commerce
top

Ce site a été crée avec le CMS Mambo. Un logiciel gratuit disponible sous licence GPL.

Copyright Ecommerce DEV 2006.

Hosted by SiteGround