Non, c'est juste qu'après, tes objets ne sont plus liés à ta session.
Il suffit de les rattacher à une nouvelle session, quand tu as en besoin.
Version imprimable
Non, c'est juste qu'après, tes objets ne sont plus liés à ta session.
Il suffit de les rattacher à une nouvelle session, quand tu as en besoin.
Et c'est là que ça pose un problème à pas mal de gens. Il faut savoir précisément si cela est nécessaire ou pas suivant le contexte ce qui peut être assez lourd lorsque les objets ont une durée de vie de plusieurs requests (dans le cas d'une application web). En plus, si l'objet détaché a été modifié il me semble que tout ce qui est mappéé en delete-orphans, hmm :aie:.Citation:
Non, c'est juste qu'après, tes objets ne sont plus liés à ta session.
Il suffit de les rattacher à une nouvelle session, quand tu as en besoin
Disons que je ne laisse pas d'objets attachés sur plusieurs requests donc je n'ai pas ce problème.
C'est là je pense la raison pour laquelle tu dis que ça va très bien de faire sans, ton raisonnement est tout à fait logique de dire que ça ne t'apporte rien. :ccool:
Ca fait partie des bonnes pratiques à la base me semble-t-il.
Oui mais c'est délicat lorsque tu souhaiterais faire de tes objets hibernate tes objets de travail (avec de la logique métier à l'intérieur) et non seulement des objets d'accès aux données.
En gros pouvoir les binder par exemple à une interface graphique pour laisser l'utilisateur en éditer les propriétés tout en profitant de cette logique métier que tu as implémenté à l'intérieur, puis ensuite les récupérer dans leur état modifié et les sauver.
Mais ça tourne vite en cuisine :mrgreen:...
Désolé d'interrompre votre dialogue mais voilà mon avis :
Hibernate a deux vocations principales :
- Pouvoir manipuler directement des DataObject plutôt que de recourir aux tables et colonnes de la BDD
- Gérer le lazy loading
Si on mappe avec une DTO et donc on fait sauter le lazy loading et qu'on est obligé de faire un mapping sur nos objets, je ne vois vraiment pas pourquoi on s'est embêté à choisir Hibernate, on peut faire la même chose avec du JDBC...
Alors :
- Soit on choisit Hibernate avec les inconvénients et les avantages qu'il possède
- Soit on prend autre chose
Mais on ne prend surtout pas Hibernate en lui appliquant les mêmes traitements que si on avait utilisé du JDBC...
Parce qu'il y a encore une sacré différence :mrgreen:.Citation:
Envoyé par sourivore
Hibernate propose du cache, du SQL dynamique, une indépendance (toute relative) avec la DB et des API de requêtage (Criteria) qui sont autrement plus sympathiques que de concaténer à la pogne des morceaux de clause WHERE et de jointures pour ne citer que cela.
Le fait que tu utilises du DTO peut signifier que pour certains objets qui franchissent le scope de ta session, tu décides d'utiliser cette surcouche par besoin d'indépenance envers les mécanismes d'hibernate. Mais il reste peut être un bon pourcentage de code qui n'est pas affecté, je pense pas que si tu fais du DTO pour un besoin précis (de communication) tu sois obligé d'être systématique.
Pour ma part, je ne mets pas de logique metier dans mes objets Hibernate, qui sont de simples Javabeans.Citation:
Oui mais c'est délicat lorsque tu souhaiterais faire de tes objets hibernate tes objets de travail (avec de la logique métier à l'intérieur) et non seulement des objets d'accès aux données.
En gros pouvoir les binder par exemple à une interface graphique pour laisser l'utilisateur en éditer les propriétés tout en profitant de cette logique métier que tu as implémenté à l'intérieur, puis ensuite les récupérer dans leur état modifié et les sauver.
Mais ça tourne vite en cuisine ...
Je les bind sans problème à mon interface Swing par sous forme détachée. Quand j'ai besoin de les modifier, je les rattache à ma session et ça roule.
Dans mon cas d'utilisation, je n'ai pas de soucis, mais visiblement, nous n'avons pas les mêmes besoins.
Dans ce cas, l'usage d'une liste paginée (genre <layout:pager> de struts-layout) posera problème dès lors que tu affiches un élément d'un objet sous-jacent... et on en revient à la problématique principale du lazy-loading...Citation:
Envoyé par fr1man
Pour moi, le plus embêtant dans hibernate, est l'absence d'une instruction "reattach(Objet)". On a bien refresh(Objet) mais le problème vient lorsqu'on a déjà modifié une partie des données.
Bref, rien est parfait...:?
Autre éclaircissement, quand je parlais d'une application one-shot, ce n'était pas lié à la complexité du modèle de données mais au fait que c'est UNE application pour UN client... Là, l'indépendance entre données et "usage/consommation" est moins important, et on a moins besoin des DTO (ce qui ne veut pas dire non plus qu'ils n'ont pas un intérêt).
Sourivore :
Le fait d'utiliser des DTO n'empêche pas d'utiliser le lazy-loading, ça n'a rien à voir. Hibernate encourage fortement l'usage du chargement "lazy" et c'est effectivement une bonne pratique (pour éviter dans certains cas qu'une lecture d'un objet ne charge tout le graphe d'objets de la base pour cause de références circulaires).
Les DTO sont des objets d'échange, liés à un besoin précis (d'une IHM ou d'un web-service par exemple). Tu peux avoir plusieurs DTO pour un groupe d'objets (Hibernate), ça t'oblige à créer des "adapateurs/convertisseurs" mais ça garanti une plus grande indépendance entre données et usage.
Imagine par exemple que tu ais besoin d'utiliser une donnée numérique ou une date sous forme de chaîne (cas pas si rare avec struts lorsqu'on veut gérer correctement la Locale du client), le fait d'utiliser le pojo directement dans l'IHM posera problème -> le DTO est une solution.
Et j'en reviens aux EJB+JTA. Dès que l'objet sort du conteneur, il est détaché (par défaut j'entends). Lorsqu'il arrive à la couche de présentation, plus moyen d'utiliser des objets référencés non chargés.
Dans ce cas, l'usage d'une liste paginée (genre <layout:pager> de struts-layout) posera problème dès lors que tu affiches un élément d'un objet sous-jacent... et on en revient à la problématique principale du lazy-loading...Citation:
Envoyé par fr1man
Pour moi, le plus embêtant dans hibernate, est l'absence d'une instruction "reattach(Objet)". On a bien refresh(Objet) mais le problème vient lorsqu'on a déjà modifié une partie des données.
Bref, rien est parfait...:?
Autre éclaircissement, quand je parlais d'une application one-shot, ce n'était pas lié à la complexité du modèle de données mais au fait que c'est UNE application pour UN client... Là, l'indépendance entre données et "usage/consommation" est moins important, et on a moins besoin des DTO (ce qui ne veut pas dire non plus qu'ils n'ont pas un intérêt).
sourivore :
Le fait d'utiliser des DTO n'empêche pas d'utiliser le lazy-loading, ça n'a rien à voir. Hibernate encourage fortement l'usage du chargement "lazy" et c'est effectivement une bonne pratique (pour éviter dans certains cas qu'une lecture d'un objet ne charge tout le graphe d'objets de la base pour cause de références circulaires).
Les DTO sont des objets d'échange, liés à un besoin précis (d'une IHM ou d'un web-service par exemple). Tu peux avoir plusieurs DTO pour un groupe d'objets (Hibernate), ça t'oblige à créer des "adaptateurs/convertisseurs" mais ça garanti une plus grande indépendance entre données et usage.
Imagine par exemple que tu ais besoin d'utiliser une donnée numérique ou une date sous forme de chaîne (cas pas si rare avec struts lorsqu'on veut gérer correctement la Locale du client), le fait d'utiliser le pojo directement dans l'IHM posera problème -> le DTO est une solution.
Et j'en reviens aux EJB+JTA. Dès que l'objet sort du conteneur, il est détaché (par défaut j'entends). Lorsqu'il arrive à la couche de présentation, plus moyen d'utiliser des objets référencés non chargés.
C'est un faux problème, cette histoire de lazy loading.Citation:
Dans ce cas, l'usage d'une liste paginée (genre <layout:pager> de struts-layout) posera problème dès lors que tu affiches un élément d'un objet sous-jacent... et on en revient à la problématique principale du lazy-loading...
Pour moi, le plus embêtant dans hibernate, est l'absence d'une instruction "reattach(Objet)". On a bien refresh(Objet) mais le problème vient lorsqu'on a déjà modifié une partie des données.
Et j'en reviens aux EJB+JTA. Dès que l'objet sort du conteneur, il est détaché (par défaut j'entends). Lorsqu'il arrive à la couche de présentation, plus moyen d'utiliser des objets référencés non chargés.
Les DTO ne résolvent rien.
C'est au développeur à savoir ce dont il aura besoin et de charger les bons objets.
Bien sûr que si, les DTO résolvent le problème puisque tu renvois un graphe complet lié à la demande
Mais ils n'apportent rien.
Tu peux très bien charger les données dont tu as besoin, sans DTO.
Si ça consiste pour toi à créer une classe qui est la copie de l'entity et d'avoir une méthode qui boucle sur les enregistrements d'une liste pour accéder au objets sous-jacents, alors oui, ça n'apporte rien...
Mais le DTO n'est pas toujours une copie de l'entity, il peut aussi redéfinir le type d'un champ pour des questions pratiques liées aux limitations de html par exemple ou à un besoin de limiter le volume (utile) de données transférées ou à un besoin d'isoler la consommation d'une donnée par rapport au modèle "physique"...
Et il restera toujours le cas EJB + JTA qui l'oblige presque...
Dans ce cas admettons, mais ça n'a rien a voir avec le lazy loading, ne mélangeons pas tout.
Et pour ce qui est des ejb/jta, je ne vois toujours pas le rapport.
Les DTO étaient "obligatoires" avec les EJB2, pour éviter les allers-retours vers le serveur.
Ce n'est plus le cas maintenant.