| « Dis monsieur, ce sera quoi le server side de demain ? | Symposium DNG, TechEd et PDC » |
Hibernate 3 et Refactoring J2EE (MAJ)
Tout comme Didier , j'ai reçu cette semaine dans ma banette les nouveaux ouvrages Java/J2EE du moment en provenance d'Eyrolles : Refactoring des applications Java/J2EE et Hibernate 3. Pour l'ensemble des livres que je reçois, j'essaie dans la mesure du possible de les lire entièrement (ou partiellement si les chapitres me sont familiers) avant d'éventuellement communiquer sur leur contenu. Ceci dit, après avoir parcouru le sommaire, puis lu "en diagonale" quelques parties de ces deux livres, on peut d'ores et déjà dire qu'Hibernate 3 est bien partie pour devenir une référence du domaine (en tout cas francophone), non seulement concernant l'outil Hibernate, mais plus généralement sur le mapping o/r. Son contenu est agréable à lire, concis et presqu'abordable pour les éventuels débutants. 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 (on m'a toujours appris que la couche de présentation ne devait jamais embarquer de dépendances vers la couche d'accès aux données). Et aussi, il faut abolir les transactions longues, en tout cas via des locks pessimistes ;-).
Un ouvrage qui doit être complété avec Hibernate en action de Gavin King.
Concernant "Refactoring avec J2EE", j'avoue que je suis plus partagé. Lorsqu'un sommaire contient des chapitres comme AOP, Junit, eXtreme Programming, Design Patterns et JDBC, j'ai du mal à trouver une cohérence d'ensemble à cet enchevaitrement de technologies, somme toute, aussi intéressantes les unes des autres. Et comment en pourrait-il être autrement, 370 pages sur un sujet aussi restreint que le Refactoring est un authentique exploit. Un titre tel que "développement agile avec J2EE/Java" aurait peut-être mieux traduit l'esprit de l'ouvrage. Ce qui n'enlève rien à sa qualité.
Sur ce, bonne lecture ...
PS : l'auteur de "Refactoring J2EE ", Jean-Philippe Retaillé vous apporte quelques précisions :
Comme vous avez indiqué dans votre blog que vous l'aviez lu en diagonale, je me permets de clarifier un point que vous évoquez, en l'occurrence que le titre ne correspond pas au contenu de l'ouvrage.
Ce point risque d'induire vos lecteurs en erreur.
En effet, celui-ci ne parle que du processus de refactoring et très peu de développement agile (en fait je ne l'évoque que dans le premier chapitre). Si effectivement, il est difficile d'écrire 370 pages sur les techniques de refactoring pures et dures (quoique Martin Fowler l'a déjà fait), mon livre va au-delà en replaçant cette activité dans le cycle de vie d'une application. En effet, les techniques de refactoring ne servent pas à grand chose si nous ne savons pas ce qu'il faut refondre ou si nous ne sommes pas en mesure d'assurer la non régression du logiciel après sa refonte par exemple.
Ainsi, mon livre aborde plusieurs outils (JUnit, PMD, CVS, etc.), non pour en donner le mode d'emploi comme pourrait le laisser penser la table des matières (seul le strict nécessaire à l'étude de cas est
fourni) mais pour montrer leur utilité dans la mise en oeuvre et l'accompagnement du refactoring. Enfin, les design patterns et l'AOP sont abordés pour montrer comment ils peuvent être introduits dans une application existante afin d'en améliorer la qualité.
J'espère que vous voudrez bien apporter ces précisions à votre blog.
Bien cordialement,
Jean-Philippe Retaillé
Un droit de réponse tout à fait légitime.
3 commentaires
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.
Mais ce n'est qu'un avis personnel ...
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.
Flux de commentaires pour cet article