Discussion :

[n!co]

Bonjour,
A chaque fois que j'ai l'impréssion de comprendre la bonne architecture a utiliser dans mon appli, je tombe sur un porblème que je ne sais pas comment résoudre !

Pour résumer mon architecture actuelle :
- Un DAO basé sur JPA et qui dialogue grace est des objets Beans (des pojos annotés)
- Un Service qui fait des appels sur mon DAO, récupère des Beans et les transforme en objets métiers.
- Une interface graphique, qui fait des appels sur mon service bet récupère les objets métier pour les afficher.

Mon problème est que je ne sais pas comment rattacher un objet métier qui aurait été modifié, autant donner que l'objet bean à l'origine, n'existe plus (nouvelle session hibernate)


Alors, je suis ok pour ne pas utiliser mes objets beans partout dans l'application, ni persister directement mes objets métier, mais la je seche sur ce problème de mise à jour

Merci d'avance

[fr1man]

Je ne suis pas certain d'avoir bien compris ton problème mais je vais essayer d'y répondre.
Dans ta couche de services, tu peux écrire des méthodes de modification
d'objets. Ces méthodes peuvent charger un objet (load par exemple) pour l'attacher à une session Hibernate. Tu les modifies dans la foulée.

Je ne vois pas ce qui te pose problème.

[n!co]

Non tu n'as pas compris, mais j'ai pas été tres clair.

Mon problème est de ne pas savoir comment réinjecter les modifications de mon objet métier dans un objet hibernate (que j'ai appellé objet bean) qui n'existe plus du fait de la nouvelle session hibernate.
Même si j'en recrée un moi même, comment va til savoir quelle ligne mettre a jour dans la bdd ?
Ou alors le fait de garder l'ID entre le passage de l'objet bean à l'objet metier, puis objet metier à l'objet bean, suffit pour pouvoir faire un merge ?

[ltournayre]

Bonjour,

Je ne crois pas que tu puisse faire un merge que sur un objet dont tu n'as plus la session hibernate qui ta servi à le recuperer.
Donc si cela est exacte tu dois :

• Soit conserver ton objet session pour pouvoir le mettre à jour
• conserver l'id dans ton objet que tu transfere, puis re-charger cette objet, le mettre à jour avec test nouvelles données, puis faire un merge

Bon courrage.

Louis

[fr1man]

Comme l'a dit ltournayre, il suffit de garder l'id de tes objets.
Du coup, rien de compliqué.
Le plus chiant, c'est la conservation de ses ids pour une application Web.
Ca peut être pénible à implémenter mais ça se fait bien.

[n!co]

Bonjour,

Je ne crois pas que tu puisse faire un merge que sur un objet dont tu n'as plus la session hibernate qui ta servi à le recuperer.
Donc si cela est exacte tu dois :

• Soit conserver ton objet session pour pouvoir le mettre à jour
• conserver l'id dans ton objet que tu transfere, puis re-charger cette objet, le mettre à jour avec test nouvelles données, puis faire un merge

Bon courrage.

Louis

Ok je m'en doutais, mais je voulais en avoir le coeur net.
C'est quand meme lourd de devoir rechager l'objet pour ensuite le modifier et pouvoir le persister.

Merci a tous les deux

[fr1man]

Ce n'est pas si lourd que ça.
Soit tu "load" ton objet par l'id et tu modifies ton objet.
Soit tu "merge" ton objet pour le reassocier à une session et tu le modifies.
Les modifications sont prises en compte au commit (selon configuration).

[n!co]

Ba si c'est c'est lourd puisse qu'en terme de requete ca fait faire un select puis un update, alors qu'un update suffit.
Merge sert a rattacher un objet détaché !
Etant donner que je ne détache aucun objet, je me demande s'il serait possible de créer mon propre nouvelle objet, lui assigner le même ID, et faire un merge dessus pour la rattacher ?

Faut que j'essaye je serais fixé

[fr1man]

Tu ne détaches peut être pas explicitement tes objets, mais ils le sont, quand ta session se termine.
Dans ce cas, il te faut bien un merge.

Je pense que c'est la façon de faire proprement.
Ce que tu proposes me semble plus être de la bidouille, mais ce n'est que mon point de vue.