Discussion :

[Nithril]

Bonjour à tous (et bonne années!)

Je cherche à mettre en place la notion de conversation dans mon application JSF utilisant Hibernate.

Cas typique dans mon application. J'ai un onglet qui s'ouvre permettant l'edition d'une donnée métier complexe avec des données en lazy loading sur plusieurs niveau.

Actuellement avec le systeme que j'ai, je suis obligé, lors de l'ouverture de l'onglet, de forcer a la main tous le chargement de mon objet pour pallier au lazy loading exception qui pourrait arriver lors de l'édition assez complexe de l'objet.

En gros je souhaiterais maintenant mettre en place un systeme qui me permettrait de pallier a ce problème. J'ouvre mon onglet, cela m'initie une conversation, je le ferme, cela l'à clos.

J'ai rapidement regardé Orchestra et Spring. Mais mon application a une spécificité dans la maniere qu'elle gere les onglets.

Les onglets sont gérés à la main via une liste de POJO. Un onglet = un POJO avec un fichier JSF.

Mes onglets

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
<c:forEach var="entry" items="#{ongletsBean.onglets}">
   <f:commandLink action="#{ongletsBean.goto}" text="#{entry.name}"/>
</c:forEach>

L'affichage du contenu de l'onglet courant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
<ui:include src="#{ongletsBean.current.url}">
   <ui:param name="data" value="#{ongletsBean.current}"/>
</ui:include>

Tous mes beans sont referencés en "data" dans les fichiers JSF. Je n'ai pas de bean managé correspondant à mes onglets.

Savez vous si avec Orchestra ou Spring (ou meme Seam) on peut mettre en place un systeme de conversation sur cette base ?


Merci d'avance pour vos réponse!

[Sniper37]

pourquoi aller loin, utilise les converters JSF.

[Nithril]

pourquoi aller loin, utilise les converters JSF.

Je vois pas trop comment les converter pourraient m'aider a mettre en place une conversation.

[Sniper37]

si tu veux passer du bean DAO issu d'hibernate à un POJO utilisé dans la vue, tu dois le faire toi même.

[Nithril]

si tu veux passer du bean DAO issu d'hibernate à un POJO utilisé dans la vue, tu dois le faire toi même.

Mais pourquoi ne pas utiliser directement le bean DAO coté vue ?

Sans que la logique métier soit coté vue, mais juste que le bean DAO soit référencé coté vue.

[Sniper37]

si tu peux, tu perd en indépendance entre la vue et le business, mais c'est courant de faire comme ça..
donc, là si tu as des valeurs à convertir de ton bean DAO, exemple, tu as un objet de type Adresse et tu veux afficher l'adresse directement comme '00 avenue de la libération 33 000 Bordeaux', là tu peux utiliser la conversion JSF.
et tu peux trouver dans la comment le faire..

[Nithril]

donc, là si tu as des valeurs à convertir de ton bean DAO, exemple, tu as un objet de type Adresse et tu veux afficher l'adresse directement comme '00 avenue de la libération 33 000 Bordeaux', là tu peux utiliser la conversion JSF.
et tu peux trouver dans la comment le faire..

Ma problématique depasse completement la notion de converter. Je ne cherche pas a afficher une donnée, mais à la charger.

En gros j'ai :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
class Role
{
   Menu rootMenu;
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
class Menu
{
   List<Menu> menus;
 
}

L'utilisateur peut editer le role et la hierarchie de menu qui l'accompagne. Pour eviter de charger toute la dépendance des menus pour pallier au lazy loading exception, je souhaite créer une conversation sur le scope d'édition de mon role.

[Sniper37]

Je ne vois là qu'un bean intermédiaire pour ça, c'est plus flexible..
c'est ce qu'on appelle le Value Object, mais, à toi de l'implémenter..

[Nithril]

Je ne vois là qu'un bean intermédiaire pour ça, c'est plus flexible..
c'est ce qu'on appelle le Value Object, mais, à toi de l'implémenter..

Ca me gene beaucoup de faire ca. C'est une surcouche que je trouve inutile alors que mon bean DAO existe et que je peux y avoir accès et donc l'utiliser.

Actuellement je charge ma dépendance d'objet a la création de l'onglet puis je fonctionne en detached.

Je vais inspecter plus profondément Orchestra et Spring.

[Tcharl]

Bonjour,

C'est super sale de mettre un DAO en vue.
Le mieux, comme dit sniper c'est d'utiliser VO( une copie de ton objet dao avec seulement des getter, une sorte d'empreinte de ton objet à un moment T). Je pense que si tu ne fais pas ça, tu auras forcément des soucis (exemple: accès concurrent d'un objet DAO dans une vue?).

Sinon, si tu utilises les EJB tu peux faire une facade remote, qui elle detache obligatoirement ton objet de la bd, et faire un session/request bean qui contient l'objet DAO comme parametre(avec qui tu communiques via ta facade)

[Nithril]

Je trouve qu'avec les ORM il devient de moins en moins evident de justifier de la creation de VO dans la mesure ou le bean hibernate est le VO. Le VO est actuellement a mon sens le bean ORM chargé et détaché.

(Apres je ne suis pas forcement tres a l'aise avec la notion de VO et le perimetre que l'on attribue a ces objets)

Actuellement je suis confronté a des soucis de lazy loading exception. Je charge donc a la main l'objet et toutes ses relations (parcours des relations pour forcer le lazy loading). A mon sens je ne devrais pas a avoir faire cela.

Une facade pourrait resoudre mon soucis. Je vais regarder ca. Merci

[TonioLeRital]

Bonjour,

j'ai longtemps fait l'usage de DTO(VO) pour exposer mes objets métiers récupérés depuis ma couche DAO hibernate vers ma couche vue.

Cette recopie d'objets permet en effet de pallier entre autres au "LazyLoadingException" mais aussi de découpler la couche vue de la couche métier (bien que dans le paradigme MVC une vue est dépendante de son modèle...).

L'avénement de framework comme Orchestra ou Seam(couplé aux EJB) permet en effet d'implémenter la nouvelle portée de variable "conversation" qui permet aussi de réutiliser une même session hibernate pour plusieurs Aller/Retour serveur. La durée de vie de cette portée est intermédiaire entre celle d'une requête et celle d'une session car bien souvent l'usage que l'on fait de la session est démesuré par rapport à la portée effective des variables qu'on lui associe.
Conceptuellement une conversation a une véritable raison d'être et c'est d'ailleurs pourquoi elle est programmée pour être intégrée dans la prochaine JSR des servlets.

Bien que des frameworks comme dozer facilite grandement la recopie BO<->VO, l'usage direct d'un BO dans la couche vue n'a rien de sale, ni dramatique et il en est de même pour l'usage des DTO...ce sont deux écoles... d'ailleurs quand il s'agit de DTO certains parlent de pattern et d'autres d'anti-pattern et j'ai longtemps été partisan de la première école.

J'adhère donc entierement aux propos de Nithril car étant donné que cela est désormais faisable par le biais de Seam ou Orchestra, je trouve dommage de continuer à utiliser des DTO pour pallier au problème du LazyLoadingException, néanmoins je continue de penser que l'usage de DTO reste justifié quand on a la contrainte de découpler la vue de son modèle.

PS: Au fait, je pense qu'au début du fil il y a eu un lapsus entre le terme "conversion" et "conversation" d'où les histoires de converters.