Guillaume Saint Etienne 's Blog - Commentaires récents sur DataBinding dans ASP.Net 2.0 et NHibernate, pas de panique (suite) http://www.dotnetguru2.org/gse/index.php?disp=comments fr-FR http://backend.userland.com/rss 60 Guillaume Saint Etienne [Membre] en réponse à: DataBinding dans ASP.Net 2.0 et NHibernate, pas de panique (suite) Sun, 07 May 2006 12:06:15 +0000 Guillaume Saint Etienne [Membre] c4269@http://www.dotnetguru2.org/ pour r&#233;pondre &#224; Bertrand Le Roy: il est &#233;vident que nous parlons ici entre grandes personnes et que, bien s&#251;r, l'UI parle &#224; des objets m&#233;tiers ou de domaine (le CRUD fait-il partie du metier? d&#233;bat!).<br /> <br /> Mais comme les colonnes de publication dans les blogs doivent rester courtes, je ne vous ai pas expos&#233; l'architecture totale de ma solution. Ceci sera expliqu&#233; dans l'article complet sur NHibernate que je pr&#233;pare. <br /> <br /> Pour le moment, je montre directement le code des op&#233;rations de la DAL, car elle travaille tout de m&#234;me, en dessous de toute couche m&#233;tier, donc il faut bien s'en occuper et c'est &#224; son niveau des exceptions sont lev&#233;es et empechait ma solution "naive" de fonctionner.
Mais comme les colonnes de publication dans les blogs doivent rester courtes, je ne vous ai pas exposé l'architecture totale de ma solution. Ceci sera expliqué dans l'article complet sur NHibernate que je prépare.

Pour le moment, je montre directement le code des opérations de la DAL, car elle travaille tout de même, en dessous de toute couche métier, donc il faut bien s'en occuper et c'est à son niveau des exceptions sont levées et empechait ma solution "naive" de fonctionner.]]> http://www.dotnetguru2.org/gse/index.php/2006/04/28/x#c4269 Denis [Visiteur] en réponse à: DataBinding dans ASP.Net 2.0 et NHibernate, pas de panique (suite) Sun, 07 May 2006 10:50:28 +0000 Denis [Visiteur] c4268@http://www.dotnetguru2.org/ <p>Je viens de tomber sur ce probl&#232;me sur un prototype ObjectDataSource + Castle ActiveRecord + Nhibernate. Tr&#232;s ennuyeux. L'origine en est que pour un Update l'ObjectDataSource appel le constructeur par d&#233;faut et ne nous laisse jamais la main pour substituer notre propre constructeur ou appeler une fonction sur une &#233;ventuelle Factory.</p><br /> <p>J'ai cru un moment que l'event OnObjectCreating pourrait nous sauver, mais il ne permet que de sp&#233;cifier la Facade de l'acc&#232;s aux objects quand les fonctions d'acc&#232;s (SelectMethod...) sont non statiques, et non les objets eux-m&#234;mes.</p><br /> <p>Je ne vois pas de solution satisfaisante mais je n'ai pas tout essay&#233; (les param&#232;tres du style UpdateParameters ?). Je suis preneur de tout workaround...</p> Je viens de tomber sur ce problème sur un prototype ObjectDataSource + Castle ActiveRecord + Nhibernate. Très ennuyeux. L'origine en est que pour un Update l'ObjectDataSource appel le constructeur par défaut et ne nous laisse jamais la main pour substituer notre propre constructeur ou appeler une fonction sur une éventuelle Factory.


J'ai cru un moment que l'event OnObjectCreating pourrait nous sauver, mais il ne permet que de spécifier la Facade de l'accès aux objects quand les fonctions d'accès (SelectMethod...) sont non statiques, et non les objets eux-mêmes.


Je ne vois pas de solution satisfaisante mais je n'ai pas tout essayé (les paramètres du style UpdateParameters ?). Je suis preneur de tout workaround...

]]> http://www.dotnetguru2.org/gse/index.php/2006/04/28/x#c4268 Bertrand Le Roy [Visiteur] en réponse à: DataBinding dans ASP.Net 2.0 et NHibernate, pas de panique (suite) Thu, 04 May 2006 22:57:08 +0000 Bertrand Le Roy [Visiteur] c4200@http://www.dotnetguru2.org/ Je peux poser une question idiote? Pourquoi ton UI parle directement &#224; ta DAL? &#199;a devrait pas plut&#244;t causer &#224; ta BL? http://www.dotnetguru2.org/gse/index.php/2006/04/28/x#c4200 Guillaume Saint Etienne [Membre] en réponse à: DataBinding dans ASP.Net 2.0 et NHibernate, pas de panique (suite) Thu, 04 May 2006 10:48:58 +0000 Guillaume Saint Etienne [Membre] c4190@http://www.dotnetguru2.org/ alors... tout cela n'est pas simple, alors qu'il s'agit des operations de Databinding les plus courament pratiqu&#233;es.<br /> <br /> Oui en effet, SaveOrUpdateCopy que j'ai tent&#233; d'utiliser semblait le plus appropri&#233;;<br /> mais il ne marche pas dans mon cas car mon objet de donn&#233;es TRestaurant poss&#232;de des relations avec d'autres objets.<br /> Du coup une exception est lev&#233;e: <i>object references an unsaved transient instance - save the transient instance before flushing: NomDeLObjetLieParTelation </i>.<br /> <br /> Sachant que dans mon detailview, je ne veux que travailler sur les donn&#233;es scalaires, par les donn&#233;es r&#233;sultantes des objets li&#233;s; il y aura d'autres IHM pour ca. Sinon on se tape la liaison &#224; l'infini de toutes les entit&#233;s d&#233;pendantes. Et on a une IHM hyper-contrainte par la couche de persistance et ce n'est pas le but non plus.<br /> <br /> Ok, le probl&#232;me peut venir aussi du schema de mapping et la facon dont sont exploit&#233;es les relations. Activer le lazy sur le mode "extra" serait une solution? Debrancher les objets entre eux par le mapping? (Je n'utilise pas le mode cascade).<br /> Il me parait peu sens&#233; de devoir adapter un schema O/R aux n&#233;cessit&#233;s des op&#233;rations de domaine. Cela devrait pouvoir se regler autrement.<br /> <br /> Mon id&#233;e etait de contr&#244;ler le databinding donn&#233; par d&#233;faut, d'une mani&#232;re acceptable pour lui (le couple NHib/Webforms) faire faire exactement ce que l'on souhaite et qu'il n'en fasse pas trop.<br /> D'o&#249; l'id&#233;e de se r&#233;-approprier la partie mise &#224; jour de donn&#233;es en faisant soi m&#234;me le choix des donn&#233;es &#224; faire updater par NHib ( et pas le laisser tout faire tout seul puisque ca se passe mal ).<br /> <br /> <br /> PS: les captures d'&#233;cran, sources et le d&#233;tail du projet viennent avec l'article en pr&#233;paration.
Oui en effet, SaveOrUpdateCopy que j'ai tenté d'utiliser semblait le plus approprié;
mais il ne marche pas dans mon cas car mon objet de données TRestaurant possède des relations avec d'autres objets.
Du coup une exception est levée: object references an unsaved transient instance - save the transient instance before flushing: NomDeLObjetLieParTelation .

Sachant que dans mon detailview, je ne veux que travailler sur les données scalaires, par les données résultantes des objets liés; il y aura d'autres IHM pour ca. Sinon on se tape la liaison à l'infini de toutes les entités dépendantes. Et on a une IHM hyper-contrainte par la couche de persistance et ce n'est pas le but non plus.

Ok, le problème peut venir aussi du schema de mapping et la facon dont sont exploitées les relations. Activer le lazy sur le mode "extra" serait une solution? Debrancher les objets entre eux par le mapping? (Je n'utilise pas le mode cascade).
Il me parait peu sensé de devoir adapter un schema O/R aux nécessités des opérations de domaine. Cela devrait pouvoir se regler autrement.

Mon idée etait de contrôler le databinding donné par défaut, d'une manière acceptable pour lui (le couple NHib/Webforms) faire faire exactement ce que l'on souhaite et qu'il n'en fasse pas trop.
D'où l'idée de se ré-approprier la partie mise à jour de données en faisant soi même le choix des données à faire updater par NHib ( et pas le laisser tout faire tout seul puisque ca se passe mal ).


PS: les captures d'écran, sources et le détail du projet viennent avec l'article en préparation.]]> http://www.dotnetguru2.org/gse/index.php/2006/04/28/x#c4190 sami [Membre] en réponse à: DataBinding dans ASP.Net 2.0 et NHibernate, pas de panique (suite) Sat, 29 Apr 2006 09:22:08 +0000 sami [Membre] c3826@http://www.dotnetguru2.org/ Ok je comprend mieux ce que tu cherches &#224; faire. Je vais essayer de r&#233;sumer :<br /> - Tu veux faire une sorte de Master/Detail avec le m&#234;me objet <br /> - Or, (et c'est logique) ASP.NET recr&#233;&#233; non seulement l'arbre des controls mais les ObjectDataSource associ&#233;s<br /> - Ta session est du type "Session Longue", du coup le cache de premier niveau est tout le temps actif (et tu n'evict() pas les objets)<br /> <br /> Du coup, c'est tout &#224; fait normal d'avoir un tel comportement. Qui plus est, Nhibernate n'en est pas la cause, tu aurais utilis&#233; n'importe quel outil de mapping, le r&#233;sultat aurait &#233;t&#233; &#224; mon avis le m&#234;me. Le mode Web fait que les graphes d'objets sont reconstruits &#224; chaque requ&#234;te. Et comme une m&#234;me session Hibernate ne peut poss&#233;der deux r&#233;f&#233;rences diff&#233;rentes pour une m&#234;me clef, l'outil l&#232;ve une exception.<br /> <br /> Par contre ta solution me semble assez inadapt&#233;e. Pourquoi faire un lock et copier des objets, alors qu'un simple lock sur modifiedData aurait suffit ou m&#234;me mieux SaveOrUpdateCopy() ?<br /> <br /> 1)<br /> [DataObjectMethod(DataObjectMethodType.Update)]<br /> public bool Modify2(X.DataEntityObjects.TRestaurants modifiedData)<br /> {<br /> nhibsession.lock(modifiedData, LockMode...)<br /> }<br /> <br /> 2) session.SaveOrUpdateCopy(modifiedData) (il copie l'objet pass&#233; en param&#232;tre avec celui attach&#233; en session mais n'attache jamais le param&#232;tre)...<br /> <br /> Et puis, si on veut encore une autre solution (celle que je pr&#233;f&#232;re) : Il vaut mieux ne jamais utiliser le mode Long lived Session sur du Web et faire de l'optimistic locking. <br /> <br /> Sami<br /> ps: guillaume,pourrais tu mettre un lien sur les sources si c'est possible? - Tu veux faire une sorte de Master/Detail avec le même objet
- Or, (et c'est logique) ASP.NET recréé non seulement l'arbre des controls mais les ObjectDataSource associés
- Ta session est du type "Session Longue", du coup le cache de premier niveau est tout le temps actif (et tu n'evict() pas les objets)

Du coup, c'est tout à fait normal d'avoir un tel comportement. Qui plus est, Nhibernate n'en est pas la cause, tu aurais utilisé n'importe quel outil de mapping, le résultat aurait été à mon avis le même. Le mode Web fait que les graphes d'objets sont reconstruits à chaque requête. Et comme une même session Hibernate ne peut posséder deux références différentes pour une même clef, l'outil lève une exception.

Par contre ta solution me semble assez inadaptée. Pourquoi faire un lock et copier des objets, alors qu'un simple lock sur modifiedData aurait suffit ou même mieux SaveOrUpdateCopy() ?

1)
[DataObjectMethod(DataObjectMethodType.Update)]
public bool Modify2(X.DataEntityObjects.TRestaurants modifiedData)
{
nhibsession.lock(modifiedData, LockMode...)
}

2) session.SaveOrUpdateCopy(modifiedData) (il copie l'objet passé en paramètre avec celui attaché en session mais n'attache jamais le paramètre)...

Et puis, si on veut encore une autre solution (celle que je préfère) : Il vaut mieux ne jamais utiliser le mode Long lived Session sur du Web et faire de l'optimistic locking.

Sami
ps: guillaume,pourrais tu mettre un lien sur les sources si c'est possible?]]> http://www.dotnetguru2.org/gse/index.php/2006/04/28/x#c3826 Tom [Visiteur] en réponse à: DataBinding dans ASP.Net 2.0 et NHibernate, pas de panique (suite) Sat, 29 Apr 2006 09:08:45 +0000 Tom [Visiteur] c3825@http://www.dotnetguru2.org/ Je serais tent&#233; de dire que c'est le data binding bidirectionnel qui est un peu simpliste, ou plut&#244;t qui a &#233;t&#233; con&#231;u pour visualiser et mettre &#224; jour des informations "&#224; plat", pas des graphes de donn&#233;es (xml ou objet). <br /> <br /> La solution pourrait &#234;tre de s'appuyer sur un framework de pr&#233;sentation Web 2.0 qui rapatrie la structure de donn&#233;es complexe c&#244;t&#233; client et en modifie le contenu directement en m&#233;moire avant de la re-transf&#233;rer sur le serveur pour mise &#224; jour. J'ai mis en oeuvre une petite appli qui ressemble &#224; &#231;a bas&#233;e sur les EJB 3 et DWR il y a quelques temps, c'&#233;tait parfait en termes de productivit&#233;. Certains frameworks .NET doivent offrir ce genre de possibilit&#233;s (pas creus&#233; pour le moment), bien plus int&#233;ressantes que le binding "bidi" c&#244;t&#233; serveur en ASP.NET 2.0 classique.<br /> <br /> Tom<br />
La solution pourrait être de s'appuyer sur un framework de présentation Web 2.0 qui rapatrie la structure de données complexe côté client et en modifie le contenu directement en mémoire avant de la re-transférer sur le serveur pour mise à jour. J'ai mis en oeuvre une petite appli qui ressemble à ça basée sur les EJB 3 et DWR il y a quelques temps, c'était parfait en termes de productivité. Certains frameworks .NET doivent offrir ce genre de possibilités (pas creusé pour le moment), bien plus intéressantes que le binding "bidi" côté serveur en ASP.NET 2.0 classique.

Tom
]]> http://www.dotnetguru2.org/gse/index.php/2006/04/28/x#c3825 yartz [Visiteur] en réponse à: DataBinding dans ASP.Net 2.0 et NHibernate, pas de panique (suite) Sat, 29 Apr 2006 08:17:47 +0000 yartz [Visiteur] c3817@http://www.dotnetguru2.org/ Ca &#233;corne un peu la r&#233;putation d'&#233;l&#233;gance d'Hibernate tout &#231;a. En gros, on a un mapping relationnel objet state of the art, qui respecte tous les patterns, fait de l'IOC, de l'AOP, et probablement trois ou quatre autres TLA, mais il faut faire par dessus du mapping objet/objet et des copies dans tous les coins parce que NHibernate n'a pas &#233;t&#233; pens&#233; pour faire de l'ASP .Net ? http://www.dotnetguru2.org/gse/index.php/2006/04/28/x#c3817 Guillaume Saint Etienne [Membre] en réponse à: DataBinding dans ASP.Net 2.0 et NHibernate, pas de panique (suite) Sat, 29 Apr 2006 01:03:21 +0000 Guillaume Saint Etienne [Membre] c3771@http://www.dotnetguru2.org/ malheureusement Session.Reconnect n'est pas la solution. Son appel l&#232;ve une exception:<br /> Exception Details: NHibernate.HibernateException: session already connected<br /> <br /> par contre oui, ceci n'est pas fait pour les objets portant des associations. Dans mon cas, il s'agit d'editer avec un DetailView un objet poss&#233;dant des donn&#233;es scalaires. Il est prudent de s'en tenir l&#224;. Et de g&#233;rer les associations &#224; part (avec un autre composant graphique par exemple).<br /> <br /> Il faudrait aller plus loin, et voir comment se comporte le 2-way data binding avec les &#233;l&#233;ments associ&#233;s. A mon avis, ca ne doit pas &#234;tre superbe et il doit falloir encore du "hand-coding". Ce sera la suite de mon &#233;tude.<br /> <br /> Ceci dit, merci pour vos commentaires. Sachant que je vous livre ici non pas LA solution, mais une solution possible. Exception Details: NHibernate.HibernateException: session already connected

par contre oui, ceci n'est pas fait pour les objets portant des associations. Dans mon cas, il s'agit d'editer avec un DetailView un objet possédant des données scalaires. Il est prudent de s'en tenir là. Et de gérer les associations à part (avec un autre composant graphique par exemple).

Il faudrait aller plus loin, et voir comment se comporte le 2-way data binding avec les éléments associés. A mon avis, ca ne doit pas être superbe et il doit falloir encore du "hand-coding". Ce sera la suite de mon étude.

Ceci dit, merci pour vos commentaires. Sachant que je vous livre ici non pas LA solution, mais une solution possible.]]> http://www.dotnetguru2.org/gse/index.php/2006/04/28/x#c3771