Discussion :

[Beuss]

PS : DTO est souvent considérer comme un anti-pattern !!! A utiliser avec précaution.

Pourrais tu développer ce point ? En effet, le DTO est cité dans le catalogue de patterns J2EE (mais peut être ont ils changé leur point de vue dessus)

[dlemoing]

Prenons ce qui est dit dans le livre Core J2EE Patterns (voir ici aussi).

Context
Application clients need to exchange data with enterprise beans.

Forces
* You want clients to access components in other tiers to retrieve and update data.
* You want to reduce remote requests across the network.
* You want to avoid network performance degradation caused by chattier applications that have high network traffic.

Consequences
* Reduces network traffic
* Simplifies remote object and remote interface
* Transfers more data in fewer remote calls
* Reduces code duplication
* Introduces stale transfer objects
* Increases complexity due to synchronization and version control

Forces : 2/3 des arguments concernent la distribution des applications
Consequences : 1/2 concernent encore la distribution des applications

Les DTO doivent être utilisés dans un but : transférer des données entre des couches distribuées (peu d'applications web ont véritablement besoin de distributions).
Pourquoi utiliser une hierarchie d'objets en parrallèle de tes objets métiers ? Pourquoi avoir des objets qui contiennent juste des données et qui n'ont pas de comportement ? (voir ici). Certains patterns de ce livre sont extremement intéressants (principalement concernant la partie présentation), je suis moins d'accord en ce qui concerne la partie métier qui propose une solution trop "EJB-centrique" à mon gout et des patterns destinés à contourner les problèmes introduits par leur solution. Lis bien la description du problème et tu verras que je ne raconte pas de betises (compte le nb de références aux EJB dans la partie "Problem").

L'utilisation d'un pattern se fait en fonction du problème à resoudre dans un contexte donné. C'est pour ca qu'il faut toujours bien lire la description du pattern (contexte, problème, forces, conséquences).
Ce pattern est donc à utiliser dans le cadre d'applications distribuées et/ou utilisant des EJB (Entity surtout).

[dlemoing]

http://martinfowler.com/bliki/LocalDTO.html

[Beuss]

Merci pour tes précisions, effectivement j'avais bien compris que les DTO étaient faits pour éviter les appels de méthodes distants et non pas pour constituer des classes utilisées uniquement pour renvoyer des données.
Il s'agit donc d'un pattern si l'on l'appelant et l'appelés passent par le réseau pour leurs échanges mais d'un anti-pattern dans les autres cas, c'est bien ça ?

[dlemoing]

Effectivement, c'est bien ca (en tout cas c'est ce que je pense et j'espère t'avoir convaincu), sauf que, si ton modèle peut être sérialisé, il n'y a toujours pas de raison pour ton DTO...
J'ajouterais juste un bémol à ce que j'ai dit précedemment : on peut éventuellement utiliser un DTO s'il y a une grosse différence entre le Domain Model et le Presentation Model (voir ce lien). Toutefois, cela doit se limiter à quelques écrans et ne doit avoir qu'un impact minime sur le design de l'application (dans tous les cas, le Domain Model ignore tout des DTO).