Discussion :

[alexc_fr]

Bonjour,
j'ai parcouru ce forum et malgré certain post intéressant, je ne trouve pas de solution au problème suivant. Pouvez vous m’aidez ?

Présentation de notre architecture :

Nous avons choisi de partir sur une architecture à 5 couches (Inspirée très fortement de celle de improve-foundations) qui est définie comme telle :

Couche « présentation » à Beans JSF et page JSF
Couches « application » et « entreprise » à Beans métier et Classes Service
Couche « ORM » à Beans et classe DAO
Couche « Persistance » à SGBD

Bien qu’elle soit très souple, cette architecture n’est pas sans poser certains problèmes.
Notre problème étant de garantir l’intégrité des données au travers de toutes ces couches.

Lors de l’affichage d’une page JSF nous n’avons pas trop de problème. Les pages JSF ont des composants qui pointent sur des attributs de nos beans JSF. Ceux-ci s’initialisent en demandant à la couche métier (via des services) de nous renvoyer un bean métier qui sert de source de données à nos beans JSF. Ces beans métiers sont eux-mêmes instanciés à partir d’un graphe d’objets VO récupéré via un appel de méthode des classes DAO (Appel réalisé dans une classe service).

Notre problème :

Lors d’une modification des données par l’utilisateur, les choses se compliquent... En effet, les données du formulaire JSF ne suffisent pas à remplir tous les champs de l’objet métier. Cet objet métier étant rempli partiellement, cela pose des problèmes pour remplir le graphe d’objet VO correspondant et ainsi persister les données saisies dans la page JSF.
(problème similaire sur l’intégrité des données MAIS inexploitable dans notre cas :
http://www.developpez.net/forums/sho....php?p=1583077 [FRANÇAIS])

Solutions possibles :

Pour garantir l’intégrité des données, nous avons trouvés plusieurs solutions, mais aucune n’est vraiment satisfaisante :

- Charger tout le graphe d’objet entre les couches.
La requête remontant le graphe VO est énorme et permet de mapper tous les champs du bean métier. Quelque soit l’écran JSF, on récupère tous les champs. Le lazy-loading sert à rien…
Gros inconvénient :
Performance très très dégradée, perte de souplesse

- Développement d’un objet métier ou graphe d’objet métier spécifique à chaque écran.
On se retrouve guidé par la base de données (domain driven developpement). Or notre base est héritée d’une application existante et pas du tout pensée pour notre nouveau projet.
Gros inconvénient :
Perte de la généricité
Multiplication du code, perte de qualité et maintenabilité

- Solution basée sur un outil de peuplement tel Dozer ou JAXB.
On a aucune idée de l’implémentation correcte de cette solution.

- Enlever la couche métier
Gros inconvénient :
Perte de souplesse et d ‘évolutivité
Contre les recommandation d’application complexe (WebServices)


En fait, nous avons pensé à beaucoup plus de solutions et nous avons fait plus de recherches que ce qui est présenté juste au dessus. Néanmoins nous essayons d’être le plus synthétique possible et espérons apporter plus de détails au travers d’un dialogue.

Nous vous remercions d’avance.

[bmarchesson]

Bonjour Alex,

Pour répondre à ton problème, le plus simple me semble de stocker ton POJO Hibernate (et les proxies qui vont avec) dans ta session HTTP. Normalement, JSF "réhydratera" de lui-même ton objet métier, avec les proxies et tu n'auras pas de problème avec Hibernate.

Sinon (application stateless), il faut recharger ton objet métier avec le même appel service que celui ayant servi à l'afficher afin d'avoir la même configuration de proxies. Ensuite, BeanLib ou Dozer te permettent simplement de peupler ton POJO Hibernate avec les valeurs de ton bean de présentation.

N'hésite pas à préciser si j'ai mal compris quelque chose

Bruno

[souviron34]

je ne connais rien aux beans et à ce dont vous parlez, mais le texte m'inspire une réflexion (j'ai été attiré sur le post par le titre, car j'ai fait beaucoup de multi-couches, mais pas avec ces technologies et langages) :

Ne serait-ce pas dû à un mauvais découpage des classes du bean métier ?

En effet, si vous dites que il est demandé lors de la mise à jour, mais qu'il est beaucoup plus gros que ce qui va être modifié, cela ne veut-il pas dire qu'il devrait être en 2 parties (2 classes distinctes, ou une classe et une sous-classe, ou une structure et une sous-structure) ? une globale, et une plus petite, concernant uniquement les champs modifiés ou suceptibles de l'être ?

Et ce serait cette dernière qui alors serait uniquement affectée par le transfert ?

Encore milles excuses si je suis complètement en dehors.....

[alexc_fr]

Bonjour,

Tout d'abord merci pour vos réponses à tous les deux.
Cependant j'ai du mal m'exprimer car vous n'avez pas tout a fait compris mon problème.

Je vais donc préciser les idées de mon précédent post en utilisant le vocabulaire du document de Bruno Marchesson (Vocabulaire généralement utilisé sur les sites anglophones) :
- Ce que j’ai appelé les beans métiers peuvent se rapprocher de la définition d’un dto d’un point de vue purement technique (getters et setters uniquement). Nous les avons appelés beans métiers car ils sont utilisés aussi dans un moteur de règles métiers (JBoss Rules) et ils serviront de base à un mapping XML dans la mise en place de webservices. Je précise donc que ces beans métiers et donc la couche à laquelle ils appartiennent nous semble indispensables et impossible à supprimer aux vues des deux besoins énoncés précédemment.
- Les beans VO sont les beans de la couches ORM, ils sont aussi communément appelés les beans du domaine.
- Nous souhaiterions ne pas être dépendant d’un framework de présentation particulier. Dans un avenir plus ou moins lointain, on aimerais pouvoir passer assez facilement à un client riche par exemple (Eclipse RCP, XUL, WPF/E …). Aussi, des frameworks tels que seam, que nous avons déjà étudié, ne semble pas être assez polyvalent et ont été écartés.

Parmi les deux réponses que vous m’avez donnée, bruno semble être celui qui a le mieux compris mon architecture. Néanmoins, aucune de ses solutions me semble adéquate dans mon cas (Du moins ce que j’en ai compris ), probablement parce que je ne l’avais pas assez détaillée.

La première solution me semble correspondre à notre solution 1 ou à notre solution 4 (J’arrive pas à savoir qu’elle est la plus proche). Comme je l’ai dit la solution 4 est INENVISAGEABLE. En terme de performance, la solution 1 et le chargement de tout le graphe de VO en session http nous semble injouable (Nous allons toutefois faire des tests …).

La deuxième solution me semble correspondre à notre solution 2 en utilisant les outils de la solution 3. Nous ne souhaitons pas avoir de DTO (nos beans métiers) dédiés à une requête spécifique d’hibernate ( équivalent, en gros, à avoir un bean métier par écran JSF ).

Nous envisageons donc d’adapter la solution de bruno, le lazykiller, à notre problème. Nous aimerions d’ailleurs connaître ton avis, bruno, sur la faisabilité de cette adaptation à notre architecture. En effet, tu est parti sur cette solution pour essayer de n’avoir qu’une seule couche d’objet (les objets du domaines) alors que nous essayons au contraire d’avoir 3 couches d’objets mais en garantissant l’intégrité des données.

[bmarchesson]

Bonjour Alex,

Je te rejoins sur le fait que charger l'ensemble du graphe d'objet est une aberration dans la plupart des cas, et que la multiplication des DTO en est une autre

L'idée que je préconise (notamment à travers la librairie LazyKiller, qui au passage, n'a qu'une faible couplage avec GWT et peut donc être utilisable dans un autre contexte) est de ne charger que partiellement un graphe d'objets (VO ou métier). Comme je l'explique sur mon blog, le problème ne se pose pas à l'affichage, mais à la modification. En effet, on remplace généralement les proxies Hibernate par un simple 'null'. Or, Hibernate interprète (de manière logique) comme une absence d'association, et donc il supprime la relation si celle-ci existait.
Il faut donc conserver une trace des objets chargés et de ceux qui ne l'ont pas été afin de mettre à jour correctement le POJO Hibernate à sauver. C'est tout l'objet de mon petit bout de code...

Pour résumer, tu es obligé au moment du clonage VO -> DTO de "marquer" les associations chargées, puis de ne recopier que celles-ci lors de la population DTO -> VO. Pour ma part, j'utilise BeanLib (qui hélas souffre d'une absence totale de doc ), car Dozer ne permet pas un clonage dynamique...

Hope this helps !
Bruno

[alexc_fr]

Rebonjour bruno,

Après avoir bien lu ton document ainsi que ta réponse précédente, nous nous sommes décidé à tester ta librairie (Un de nos collègues, qui s’appelle bruno aussi , avait d’ailleurs proposer une idée similaire).
Par contre, vu nos besoins nous allons probablement la modifier. Nous te tiendrons au courant des changements et des résultats soit sur ce post, soit sur ton blog, soit directement par mail .

PS : Au fait moi c'est stephane ! J'emprunte le compte d'un collegue .

[bmarchesson]

ok Stéphane
Tiens-moi au courant pour la librairie. Je l'enrichis aussi de mon coté, tout en pensant peut-être lui donner un coté plus structuré.

Bruno