DTOs pourquoi ?

Les DTOs ou Data Transfert Objects sont des POJOs Java servant à véhiculer des données la plupart du temps entre la couche présentation et la couche métier au sein d'une même application. Certains les appellent Value Objects (VO), d'autres Beans en réference à la spec java beans.

DTOs pourquoi?

Ce pattern a été mis en place avec l'arrivée des spec EJB 1.x, CMP et les fameux et très controversés entity beans. En effet les entity beans étaient des EJBs à part entière avec une interface locale ou distante et n'étaient pas sérialisables! C'est là que se trouvait le problème.
Il était donc impossible de faire passer par le réseau un entity beans lors d'une communication de type remote. Il fallait pour cela copier l'entity bean dans un nouvel objet sérialisable afin de pouvoir le faire transiter : le DTO.
Par ailleurs, pour les utilisations des entity beans via leurs interfaces locales, un entity bean restait toujours connecté, s'il était transmit tel quel à la couche présentation, toute modification de l'objet par cette dernière aurait pour conséquence une mise à jour directe de la donnée en base.

Le DTO est-il vraiment mort?

La persistance est sortie des specs EJB 3.0 et 3.1, et est portée par la spec JPA. une entitée JPA est un POJO avec des métadonnés (annotations) permettant au moteur de persistance de persister le POJO en base de données. Ces POJO sont sérialisables et donc véhiculables à travers le réseau, de plus, la notion de scope de persistance permet de garantir que les POJOs retournés en sortie d'une méthode sont automatiquement déconnectés de la base par exemple.

Le pattern DTO n'est donc plus obligatoire, il reste selon moi toujours utile lorsque l'affichage d'une page nécessite un ou plusieurs sous ensembles d'entités différentes. Le DTO permet dans ce cas d'avoir un objet d’agrégation et de ne renvoyer à l'IHM qu'un seul objet contenant par contre toutes les informations nécessaires à l'affichage.