Quel est l'intérêt d'utiliser les DTO (Data Transfer Objects)?
Le DTO est un modèle et il est indépendant de l'implémentation (POJO/POCO). Selon le DTO, étant donné que chaque appel vers une interface distante coûte cher, la réponse à chaque appel devrait apporter autant de données que possible. Ainsi, si plusieurs demandes sont nécessaires pour apporter des données pour une tâche particulière, les données à apporter peuvent être combinées dans un DTO afin qu'une seule demande puisse apporter toutes les données requises. Catalogue des modèles d'architecture d'application d'entreprise a plus de détails.
Les DTO sont un concept fondamental, pas dépassé.
Le DTO en tant que concept (objets dont le but est de collecter des données à restituer au client par le serveur) n'est certainement pas dépassé.
Ce qui est quelque peu dépassé est la notion d'avoir des DTO qui ne contiennent aucune logique, sont utilisés niquement pour transmettre des données et "mappés" à partir d'objets de domaine avant la transmission au client, et il mappé pour afficher les modèles avant de les passer à la couche d'affichage. Dans les applications simples, les objets de domaine peuvent souvent être directement réutilisés en tant que DTO et transmis directement à la couche d'affichage, de sorte qu'il n'existe qu'un seul modèle de données unifié. Pour les applications plus complexes, vous ne souhaitez pas exposer l'intégralité du modèle de domaine au client, un mappage des modèles de domaine aux DTO est donc nécessaire. Avoir un modèle de vue distinct qui duplique les données des DTO n'a presque jamais de sens.
Cependant, la raison pour laquelle cette notion est dépassée plutôt que tout simplement erronée est que certains cadres/technologies (principalement plus anciens) l'exigent, car leurs modèles de domaine et de vue ne sont pas POJOS et sont plutôt directement liés au cadre.
Plus particulièrement, les Entity Beans dans J2EE avant la norme EJB 3 n'étaient pas des POJO et étaient plutôt des objets proxy construits par le serveur d'application - il n'était tout simplement pas possible de les envoyer au client, vous n'aviez donc pas le choix d'avoir une couche DTO distincte - c'était obligatoire.
Bien que le DTO ne soit pas un modèle obsolète, il est souvent appliqué inutilement, ce qui peut le faire paraître obsolète.
De Java gourou Adam Bean:
Le modèle le plus mal utilisé dans la communauté Java Enterprise est le DTO. Le DTO a été clairement défini comme une solution à un problème de distribution. Le DTO était censé être un conteneur de données à grain grossier qui transporte efficacement les données entre processus (niveaux). ~ Adam Bien
De Martin Fowler:
Les DTO sont appelés Data Transfer Objects parce que leur objectif est de déplacer des données dans des appels distants coûteux. Ils font partie de l'implémentation d'une interface à gros grain dont une interface distante a besoin pour les performances. Non seulement vous n'en avez pas besoin dans un contexte local, mais ils sont en fait nuisibles à la fois parce qu'une API à granularité grossière est plus difficile à utiliser et parce que vous devez faire tout le travail en déplaçant les données de votre couche de domaine ou de source de données vers les DTO. ~ Martin Fowler
Voici un exemple Java EE spécifique d'un usage courant mais incorrect du modèle DTO. Si vous n'êtes pas familier avec Java EE, il vous suffit de connaître le modèle MVC: un "JSF ManagedBean" est une classe utilisée par la vue, et une "entité JPA" est le modèle du modèle MVC.
Par exemple, disons que vous disposez d'un JSF ManagedBean. Une question courante est de savoir si le bean doit contenir directement une référence à une entité JPA, ou doit-il conserver une référence à un objet intermédiaire qui est ensuite converti en une entité. J'ai entendu cet objet intermédiaire appelé DTO, mais si vos ManagedBeans et Entities fonctionnent au sein de la même JVM, alors il y a peu d'avantages à utiliser le modèle DTO.
De plus, considérez les annotations de validation de bean (encore une fois, si vous n'êtes pas familier avec Java EE, sachez que la validation de bean est une API pour valider les données). Vos entités JPA sont probablement annotées avec @NotNull et @ Validation de la taille. Si vous utilisez un DTO, vous voudrez répéter ces validations dans votre DTO afin que les clients utilisant votre interface distante n'aient pas besoin d'envoyer un message pour savoir qu'ils ont échoué à la validation de base. Imaginez tout cela travail supplémentaire de copie des annotations de validation de bean entre votre DTO et l'entité, mais si votre vue et vos entités fonctionnent au sein de la même machine virtuelle Java, il n'est pas nécessaire d'effectuer ce travail supplémentaire: utilisez simplement les entités.
Le lien d'IAmTheDude vers Catalogue des modèles d'architecture d'application d'entreprise fournit une explication concise des DTO, et voici d'autres références que j'ai trouvées éclairantes:
Absolument pas! Tout récemment, j'ai appris des leçons sur la meilleure utilisation des DTO plutôt que sur votre objet métier que vous utilisez (éventuellement lié à votre mappeur ORM).
Cependant, utilisez-les simplement lorsqu'elles sont appropriées et pas seulement pour les utiliser, car elles sont mentionnées dans un bon livre de modèles.
Un exemple typique qui me vient à l'esprit est lorsque vous exposez une sorte d'interface à des tiers. Dans un tel scénario, vous souhaitez garder les objets échangés assez stables, ce que vous pouvez généralement bien faire avec les DTO.
J'ai trouvé que les DTO étaient particulièrement utiles pour contenir la logique des réponses API. Avec ce modèle, il est facile de gérer différents types de réponses à partir d'objets vers différents formats de manière testable. En utilisant ce modèle dans mon rôle actuel, nous avons pu commencer à tester les formats de réponse pour nos API, ce qui est précieux car notre pile devient plus isomorphe avec divers clients (http/mobile). Certainement pas obsolète.