http://www.dotnetguru2.org/sami/index.php?disp=comments fr-FR http://backend.userland.com/rss 60 Mon, 20 Jun 2005 20:19:32 +0000 Anthony Patricio [Visiteur] c625@http://www.dotnetguru2.org/ bonjour, je suis l'auteur du livre Hibernate.<br /> Merci de l'avoir et merci pour le commentaire positif.<br /> Concernant le filtre de servlet. On ne peut pas dire que le filtre de servlet fasse partie de la vue... ce n'est pas vrai, le filtre de servlet joue le role d'intercepteur et en ce sens peut parfaitement prendre le role d'observateur dans un pattern observateur/observ&#233;, ce que je decris dans mon livre.<br /> Pour autant, je rejoins compl&#232;tement la remarque de sami, il est toujours pr&#233;f&#233;rable que le d&#233;veloppeur sache charger son graphe d'objet use case par use case, c'est important pour les performances (&#233;viter le probl&#232;me du n+1 select).<br /> Pour les environnements JTA, je vous conseille de regarder la nouvelle foncitonnalit&#233; sessionFactory.getCurrentSession().<br /> Concernant cette remarque "il faut abolir les transactions longues, en tout cas via des locks pessimistes", biiipp, il faudra relire le chapitre. Les transaction bas niveau (bdd) longues sont une catastrophe et en ce sens tu as completement raison. Par contre ce que je decris dans le livre c'est une transaction applicative longue, qui ne laisse ni de transaction bdd ni de connexion bdd ouverte. Tout cela est g&#233;r&#233; grace &#224; l'aspect cache de premier niveau qu'est la session. Moi je conseille de l'utiliser des qu'on ne fait pas de replication de session http et si on se sens capable de bien definir les transactions longues mais &#231;a n'est que mon avis.<br /> <br /> Merci encore pour vos remarques, n'hesitez pas si vous avez besoin d'infos.<br /> <br /> <br /> Merci de l'avoir et merci pour le commentaire positif.
Concernant le filtre de servlet. On ne peut pas dire que le filtre de servlet fasse partie de la vue... ce n'est pas vrai, le filtre de servlet joue le role d'intercepteur et en ce sens peut parfaitement prendre le role d'observateur dans un pattern observateur/observé, ce que je decris dans mon livre.
Pour autant, je rejoins complètement la remarque de sami, il est toujours préférable que le développeur sache charger son graphe d'objet use case par use case, c'est important pour les performances (éviter le problème du n+1 select).
Pour les environnements JTA, je vous conseille de regarder la nouvelle foncitonnalité sessionFactory.getCurrentSession().
Concernant cette remarque "il faut abolir les transactions longues, en tout cas via des locks pessimistes", biiipp, il faudra relire le chapitre. Les transaction bas niveau (bdd) longues sont une catastrophe et en ce sens tu as completement raison. Par contre ce que je decris dans le livre c'est une transaction applicative longue, qui ne laisse ni de transaction bdd ni de connexion bdd ouverte. Tout cela est géré grace à l'aspect cache de premier niveau qu'est la session. Moi je conseille de l'utiliser des qu'on ne fait pas de replication de session http et si on se sens capable de bien definir les transactions longues mais ça n'est que mon avis.

Merci encore pour vos remarques, n'hesitez pas si vous avez besoin d'infos.


]]> http://www.dotnetguru2.org/sami/index.php/2005/06/16/hibernate_3_et_refactoring_j2ee#c625 Thu, 16 Jun 2005 18:53:42 +0000 sami [Membre] c624@http://www.dotnetguru2.org/ D&#233;porter la couche d'acc&#232;s aux donn&#233;es c&#244;t&#233; Web est un anti-pattern d'architecture. Que se passe t-il le jour o&#249; on d&#233;cide de connecter un client Swing ou SWT ? C'est &#224; l'utilisateur de compl&#233;ter son graphe d'objet pour &#233;viter de tomber sur une exception de Lazy Loading, pas &#224; une servlet :-) <br /> Mais ce n'est qu'un avis personnel ... Mais ce n'est qu'un avis personnel ...]]> http://www.dotnetguru2.org/sami/index.php/2005/06/16/hibernate_3_et_refactoring_j2ee#c624 Thu, 16 Jun 2005 17:22:31 +0000 Alex [Visiteur] c623@http://www.dotnetguru2.org/ <blockquote>Il faudra simplement que les d&#233;veloppeurs d'Hibernate m'expliquent un jour ce qu'ils trouvent d'&#233;l&#233;gant dans l'impl&#233;mentation d'un HibernateContext (Session) g&#233;r&#233; par un Servlet Filter</blockquote><br /> La meilleure raison, c'est pour pouvoir profiter du "lazy loading" au niveau de la vue(JSP). <br /> Si on ne met pas une gestion de la session dans le filtre et qu'on essaye de parcourir une collection "lazy"(i.e. charg&#233;e &#224; la demande) dans une JSP, on r&#233;cupere une belle exception en plein dans la t&#234;te...<br /> Donc m&#234;me si c'est pas tr&#232;s beau, c&#224; permet de profiter du chargement d'objet &#224; la demande(lazy loading) dans les JSP.<br /> <br /> La doc Hibernate <a href="http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#transactions-basics-uow" rel="nofollow">en parle aussi</a> un peu. Il faudra simplement que les développeurs d'Hibernate m'expliquent un jour ce qu'ils trouvent d'élégant dans l'implémentation d'un HibernateContext (Session) géré par un Servlet Filter
La meilleure raison, c'est pour pouvoir profiter du "lazy loading" au niveau de la vue(JSP).
Si on ne met pas une gestion de la session dans le filtre et qu'on essaye de parcourir une collection "lazy"(i.e. chargée à la demande) dans une JSP, on récupere une belle exception en plein dans la tête...
Donc même si c'est pas très beau, cà permet de profiter du chargement d'objet à la demande(lazy loading) dans les JSP.

La doc Hibernate en parle aussi un peu.]]> http://www.dotnetguru2.org/sami/index.php/2005/06/16/hibernate_3_et_refactoring_j2ee#c623