Quel est l'intérêt d'utiliser DTO et s'agit-il d'un concept obsolète? J'utilise des POJO dans la couche de vue pour transférer et conserver des données. Ces POJO peuvent-ils être considérés comme une alternative aux DTO?
java
design-patterns
Vinoth Kumar CM
la source
la source
Réponses:
DTO est un modèle indépendant de la mise en oeuvre (POJO / POCO). Selon DTO, comme chaque appel vers une interface distante est coûteux, la réponse à chaque appel devrait apporter le plus de données 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. Le catalogue des modèles d’architecture d’applications d’entreprise contient plus de détails.
Les DTO sont un concept fondamental, pas obsolète.
la source
DTO en tant que concept (objets dont le but est de collecter des données à retourner au client par le serveur) n'est certainement pas obsolète.
Ce qui est quelque peu dépassé est la notion de DTO ne contenant aucune logique, utilisés uniquement pour la transmission de données et "mappés" depuis des objets de domaine avant la transmission au client, puis mappés pour afficher les modèles avant de les transmettre à 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 des applications plus complexes, vous ne souhaitez pas exposer l'intégralité du modèle de domaine au client. Par conséquent, un mappage des modèles de domaine vers des DTO est nécessaire. Avoir un modèle de vue séparé 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 simplement fausse est que certains frameworks / technologies (principalement les plus anciens) le requièrent, car leurs modèles de domaine et de vision ne sont pas des POJOS mais sont directement liés au framework.
Plus particulièrement, les Entity Beans dans J2EE avant la norme EJB 3 n'étaient pas des objets POJO, mais des objets proxy construits par le serveur d'applications. Il n'était tout simplement pas possible de les envoyer au client. - c'était obligatoire.
la source
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.
Par exemple, supposons que vous ayez un JSF ManagedBean. Une question commune 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 déjà entendu cet objet intermédiaire appelé DTO, mais si vos ManagedBeans et vos entités opèrent au sein de la même machine virtuelle, l'utilisation du modèle DTO présente peu d'avantages.
Examinez les annotations de validation de bean. Vos entités JPA sont probablement annotées avec les validations @NotNull et @Size. 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 ce travail supplémentaire de copie des annotations de validation de bean entre votre DTO et votre entité, mais si votre vue et vos entités fonctionnent au sein de la même machine virtuelle, il n’est pas nécessaire de s’acquitter de ce travail supplémentaire: utilisez simplement les entités.
Le lien de IAmTheDude au Catalogue de modèles d’architecture d’applications d’entreprise fournit une explication concise des DTO, et voici d’autres références éclairantes:
la source
Absolument pas! Récemment, j’ai appris à mieux utiliser les DTO plutôt que votre objet d’entreprise que vous utilisez (éventuellement lié à votre mappeur ORM).
Cependant, utilisez-les seulement quand elles conviennent, et pas seulement pour les utiliser, car elles sont mentionnées dans un bon cahier de modèles.
Un exemple typique qui me vient à l’esprit est celui de l’exposition d’une interface à une tierce partie. Dans ce cas, vous voudriez que les objets échangés soient assez stables, ce que vous pouvez généralement obtenir avec les DTO.
la source
J'ai trouvé que les DTO sont 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, allant d'objets à 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 de nos API, ce qui est très utile car notre pile devient de plus en plus isomorphe avec divers clients (http / mobile). Certainement pas démodé.
la source