« Patrons de conception/Façade » : différence entre les versions

Contenu supprimé Contenu ajouté
Aucun résumé des modifications
m Mauvais copié collé de http://knotty.developpez.com/j2ee/ejb/
Ligne 4 :
 
La façade encapsule la complexité des interactions entre les business objects participant à un workflow.
 
Remarque: le reste de l'article me semble hors sujet ou alors trop ciblé sur un problème particulier (assez contradictoire avec la philosophie design pattern)
 
En [[programmation orientée objet]], '''façade''' est un [[motif de conception]] (''design pattern'').
 
'''MODELE DE DONNEES :'''
 
un forum de discution composé de :
 
· POST. Un Post est un message.
 
· FORUM. Un Forum est un regroupement de Posts. Nous aurons plusieurs Forums, par exemple l’un qui s’appelle [[JAVA]] et l’autre [[J2EE]].
Le modèle présenté est une façon simple de représenter notre système. Nous avons une relation one-to-many entre POST et FORUM, ce qui signifie qu’un FORUM peut contenir plusieurs POSTs. Un POST a un POST parent, c’est notre façon de représenter un fil (suite de POSTs).
 
'''SESSION FACADE :'''
Le problème est le suivant : Chaque appel distant est coûteux, il faut trouver un moyen de les limiter. Une Session Façade est un session bean qui a accès aux interfaces locales d’autres beans (parce qu’il vit dans la même JVM). Un appel à une méthode d’un Session Façade entraîne généralement plusieurs appels vers un ou plusieurs autres beans. Supposons par exemple le cas suivant :
 
Un modérateur veut déplacer un fil (série de POSTs) d’un FORUM vers un autre. Nous avons ces étapes :
 
1. Trouver le premier POST du fil à déplacer
 
2. Trouver tous les POST qui suivent le fil
 
3. Déplacer chacun des POSTs
 
Le modérateur ne veut se soucier que du fait qu’il déplace un fil. Notre Session Façade va posséder la méthode deplaceFile qui prend comme argument l’identifiant d’un POST.
 
Le réseau se trouve entre le serveur WEB ([[Servlet]] Container, ou SC) et la Façade. Les appels entre Façade et POST CMP sont locaux. Notre opération ne requiert qu’un seul appel distant, quel que soit le nombre de POSTs à déplacer.
 
De façon générale, c’est un bon exercice de ne pas générer d’interfaces distantes pour ses EJB persistants. En d’autres termes, une façade porte bien son nom, un mur entre application et persistance.
 
Notre façade pourrait faire tout un tas d’autres choses, comme par exemple vérifier l’autorisation de l’utilisateur qui a instancié la requête. Une façade peut aussi appeler d’autres Session Beans ou Message Driven Beans. La leçon à retenir étant qu’il faut limiter le nombre d’appels distants.
 
{{Informatique}}