utilité du design pattern DTO

Bonjour,
je veux bien savoir l'utilité du design pattern DTO qui permet de donner une nouvelle représentation épuré de l'objet,si il y a des ORM comme hibernate qui permettent d'implémenter ce qu'on appelle le LAZY LOADING qui à son tour fait la même chose presque
Merci de votre interaction

Les DTO sont souvent qualifiés d'inutiles dans un contexte JPA/ORM mais c'est un point de vue restrictif et qui ne tient pas compte des contraintes de certains environnements/architectures.

Les DTO n'ont pas grand chose à voir avec le lazy loading, même si en général, ils évitent cette exception.
L'avantage majeur que j'y vois est l'isolation de l'application de la structure physique d'une base de données. On peut donc faire varier la DB sans avoir à toucher l'application utilisatrice.
Un autre avantage est que les DTO représentent uniquement les données utilisées par l'IHM.
Enfin, avec certaines bases de données à l'ancienne, on va également pouvoir donner un nom significatif à une colonne... ce n'est pas rien !
"DTVA" ne veut pas dire grand chose... "DateDeValidation" est un peu plus explicite ;)

merci de votre réponse ubutterline
je vais vous mettre dans la situation:
supposons que nous avons deux classes qui ont une association bidirectionnelle entre eux par exemple une catégorie a plusieurs produit j'utilise DTO pour éviter le problème quand je sélectionne une catégorie cet objet instance de catégorie contiendra une collection d'objet produit et vice versa,mais je me retrouve avec le fait que le lazy loading fait la même chose il récupère l'objet catégorie et des proxy vers les objets produits qui lui appartiennent ,donc je me suis dit c'est quoi l'utilité du design pattern DTO

Tu parles d'une relation <many-to-many> ?

Dans tous les cas, l'intérêt des DTO n'est pas dans le lazy-loading et je ne dis pas non plus qu'on DOIT absolument passer par des DTO.
On peut très bien développer sans, en particulier si la base de données est figée...
C'est d'autant plus vrai si les DTO sont des classes identiques aux entity...
Dans le temps, surtout si la base de données sert à plusieurs applications, l'intérêt des DTO est plus grand.

Pour ton cas particulier, j'aurais :
- un DTO lié à la vue par Catégorie contenant une liste de DTO avec les informations produit affichées par cette vue
- un DTO lié à la vue Produit contenant une liste de DTO avec les informations Catégorie affichées par cette vue

Rien n'empêche d'utiliser les mêmes objets de base en les étendant.
On pourrait imaginer avoir un objet DTOCategorie avec code, libellé (et tout ce qui est affiché) et une extension de cet objet ajoutant la liste de DTOProduit. On aurait donc :
- un DTOCategorie
- un DTOVueCategorie extends DTOCategorie avec une List<DTOProduit>
- un DTOProduit
- un DTOVueProduit extends DTOProduit avec une list<DTOCategorie>

Tu vois mieux ?

j'ai plutôt une association ManytoOne:categorieDTO contient une liste d'Id produit quand je veux construire un categorieDTO à partie d'un objet Categorie j'utilise une méthode similaire à :

Code:

---

1 2 3 4 5 6 7 8 9 10

public CategorieDTO createDTO(Categorie cat){ CategorieDTO dto=new CategorieDTO(); ... ArrayList<Long> idProduits =new ArrayList<Long>(); for(Produit p:p.getProduits){ idProduits.add(p.getId()); } dto.setProduits(idProduits); .... }

---

mais j'obtient une exception :LazyInitialisationException:failed to initialize a collection of role no session or session was closed