Discussion :

[cyrilforever]

Bonjour à tous,



Voilà j' ai une petite question technique.
J' ai environ 15 entity beans et je n'ai créé qu'un seule facade.(facade distante)

Ma question est de savoir comment puis je simplifier la lisibilité et la compréhension de ma facade distante.
Ce que je veux dire c'est que dans cette dernière est présent toutes les méthodes add/remove/list.. de mes entity beans. Cela fait donc nbEntityBeans * 4 methodes dans ma facade sans compter les méthodes métiers nécessaires.

Pour résoudre ce problème, j' ai pensé à plusieurs choses et j'aimerai savoir ce que vous ne penser.

1) creer des sessions beans stateless locales pour mes entity beans locales. Ces sessions beans locales seront ensuite reliées a ma facade (principale) distante.

2) Création d'un entity bean A effectuant un lien avec entity bean B, C.
Ainsi seule le bean A fera les actions sur B,C. En répétant cette opération (ou hiérarchisation) nous passerons au final que les entity "meres" a la facade distante.

Voila qu'en pensez vous? Avez vous d'autres idées.??

[Claythest]

Si j'ai bien tout compris, la meilleure solution est la solution 1, puisqu'il existe un design pattern associé et reconnu : les Helper

En fait ton session de facade va communiquer avec plusieurs plus petits session bean stateless qui s'occuperont chacun d'un travail précis (genre : manipulation de l'entity bean toto...).

Ca c'est si j'ai bien tout compris, car je ne l'ai pas encore implémenté (mais ca ne saurait tarder) et donc je n'ai aucune expérience en la matière... Cependant c'est ce que j'ai lu et compris

[cyrilforever]

donc il existe un pattern pour cela... ok je vais fouiller du coté du pattern que tu m'as cité.
mais pourquoi ne l'as tu jamais implémenté? est ce que c'est utile de séparer les méthodes d'un bean dans une classe temporaire??

[Claythest]

Je ne l'ai jamais implémenté car je n'en suis pas encore à cette étape
Je débute moi aussi en EJB

C'est tout

Mais c'est prévu

[cyrilforever]

ok!! mais comment es tu sûr que c'est ce pattern qu'il faut utiliser et pas un autre?? tu as un cours dessus?

[Claythest]

J'ai reçu le conseil d'un professeur... Et c'est pour ça que je soumet quelques réserves puisque personnellement je ne l'ai jamais utilisé... donc si un autre lecteur de ce topic pouvait donner son avis

Cependant, ce design pattern me paraît logique et efficace, donc tout bon

En plus il est pas du tout compliqué à mettre en place et raccourcira vraiment la taille de ton session facade tout en séparant mieux les rôles et sans pertes de performances

[manblaizo]

Bonjour à tous,

Voilà j' ai une petite question technique.
J' ai environ 15 entity beans et je n'ai créé qu'un seule facade.(facade distante)

Ma question est de savoir comment puis je simplifier la lisibilité et la compréhension de ma facade distante.
Ce que je veux dire c'est que dans cette dernière est présent toutes les méthodes add/remove/list.. de mes entity beans. Cela fait donc nbEntityBeans * 4 methodes dans ma facade sans compter les méthodes métiers nécessaires.

Pour résoudre ce problème, j' ai pensé à plusieurs choses et j'aimerai savoir ce que vous ne penser.

1) creer des sessions beans stateless locales pour mes entity beans locales. Ces sessions beans locales seront ensuite reliées a ma facade (principale) distante.

2) Création d'un entity bean A effectuant un lien avec entity bean B, C.
Ainsi seule le bean A fera les actions sur B,C. En répétant cette opération (ou hiérarchisation) nous passerons au final que les entity "meres" a la facade distante.

Voila qu'en pensez vous? Avez vous d'autres idées.??

Salut,
D'abord je voudrais dire que si tu as au moins 15 entity beans, il me semble peu probable que tous ces entity beans participent à un seul cas d'utilisation. Il n'est pas recommandé d'avoir un seul session façade pour toute l'application, mais au moins un session façade par cas d'utilisation. Et à partir de là tu verras qu'il n'y aurait plus que deux voire trois entity beans à relier à chacun des session façade. Ensuite un session façade ne devrait pas exposer toutes les méthodes get/set des entity beans qu'il est censé encapsuler, mais il doit présenter plutot des méthodes "coarse-grained" qui ensuite font appel aux entity beans pour composer et générer le résultat à renvoyer au client. Si tu développes en EJB 2.x tu pourrais aussi faire usage du pattern "Data Transfer Object" pour le transfert de données entre la couche métier et la couche présentation, ce qui te permettrait de composer des données dans le session façade à partir des entity beans pour les renvoyer dans un seul objet à la couche présentation.
Voilà à peu près ce que je peux dire pour l'instant.
Bon courage.

[cyrilforever]

ok. donc il y a deux solutions distinctes l'une de l autre:

1) pattern: helper.
2) ou décomposer mon appli en plusieurs facades dont chacune correspond a un cas d'utilisation.

Mais utiliser plusieurs facades n'entraine t il pas des problèmes de performances? Qu'y a t il de différents(avantages,e t inconvénients) entre l'utilisation des helpers?

PS: je développe en ejb 2.1

[manblaizo]

ok. donc il y a deux solutions distinctes l'une de l autre:

1) pattern: helper.
2) ou décomposer mon appli en plusieurs facades dont chacune correspond a un cas d'utilisation.

Mais utiliser plusieurs facades n'entraine t il pas des problèmes de performances? Qu'y a t il de différents(avantages,e t inconvénients) entre l'utilisation des helpers?

PS: je développe en ejb 2.1

Je ne sais pas de quel "Helper" il s'agit ici, le pattern J2EE que je connaisse avec un nom similaire c'est le "View Helper" qui est plutot un pattern de la couche présentation. Mais en tout cas, concernant ta solution 1) qui consiste à mettre des session beans entre le session façade et les entity beans, c'est ni plus ni moins que l'ajout d'une couche d'indirection de plus, et cela dépend de la taille de ton projet. Plus le projet est de grande taille, plus tu auras besoin d'ajouter des couches d'indirection pour plus de lisibilité et de facilité de maintenance, mais si le projet est petit le session façade peu directement accéder aux entity beans. Dans le jargon des patterns J2EE, ta solution 1) correspond au pattern "Application Service" (voir livre "J2EE Patterns, 2nd edition"). Mais peu importe vraiment la façon dont tu le nommes, l'important c'est que ton code soit bien structuré.
Concernant le nombre des session façade dans ton application, c'est comme je l'ai dit, tu peux en avoir autant que tu as des cas d'utilisation, chacun gérant l'ensemble des interactions utilisateur liées à un cas d'utilisation. Il n'y a aucun problème de performance, au contraire, puisque chaque session façade ne s'occupe que d'un ensemble de taches liées entre elles. Tu gagnes en lisibilité et en cohérence pour ton code.
Tu utilises EJB 2.1, alors pense aussi aux DTO (Data Transfer Object), c'est la meilleure façon de transférer les données entre les différentes couches de ton application.
Voilà, bon courage.

[cyrilforever]

merci de ta réponse claire et précise. En utilisant plusieurs facades, et la DTO, je peux si besoin est rajouter une couche d'indirection via des sessions beans stateless entre ma facade1 et des entity beans, cest bien ca?!