Je voudrais comprendre quels sont les avantages de créer des objets DTO lorsque vous avez déjà un objet POJO (en tant qu'entité).
Dans mon projet, j'ai les deux:
Si je regarde une classe d'objets DTO (appelons-la MyObjDTO) et la même classe mais côté POJO (appelons-la MyObjPOJO), il n'y a aucune différence sauf MyObjPOJO comme annotation car c'est une @Entity.
Donc en fait, j'ai dans mon projet 2 classes qui se ressemblent (mêmes attributs, mêmes méthodes) mais pour des puproses différentes.
IMO, dans ce cas, la classe DTO est inutile et augmente la complexité de l'application car tout ce que je fais avec la classe DTO je peux le faire avec ma classe POJO et de plus, pour un seul type d'objet, je dois maintenir au moins 2 classes (le DTO et POJO), par exemple si j'ajoute un attribut, je dois ajouter cet attribut dans les deux classes.
Je ne suis pas un expert et je m'interroge sur mes pensées; Qu'est-ce que tu en penses ?
3 Réponses :
La plupart de cela se résume à une architecture propre et à une concentration sur la séparation des préoccupations
Mon plus grand cas d'utilisation pour les entités est de ne pas joncher les DTO avec des variables d'exécution ou des méthodes que j'ai ajoutées pour plus de commodité (telles que les noms / valeurs d'affichage ou les valeurs post-calculées)
Si c'est une entité très simple, alors il n'y a pas grand-chose à ce sujet, mais si vous êtes extrêmement strict avec Clean, il devient alors beaucoup de modèles redondants (DTO, DBO, Entity)
C'est vraiment une préférence dans ce que vous voulez consacrer à une architecture propre stricte
https://medium.com/android-dev-hacks/detailed-guide-on-android-clean-architecture-9eab262a9011
Merci pour votre réponse chère mais cela ressemble à une architecture propre VS un code simple. Je veux penser que c'est plus profond. Dans mon cas, je pense que DTO a été implémenté sans y penser; le développeur pense que "DTO consiste à transférer un objet, alors je fais du DTO" au lieu de penser qu'il pourrait utiliser la classe POJO à la place de DTO (pour mon cas du moins)
Non, ce n'est pas le cas. Le lien fourni ne dit rien sur les DTO. Votre idée du DTO ne correspond pas à son objectif déclaré, une fois que vous vous en souciez. Tout sur la planète n'est pas fait dans un but de propreté, du moins pour certaines personnes, l'oncle Bob Martin parmi eux. Btw nous sommes dans le mauvais forum et la question devrait être close.
Cette réponse est une réplique de ce qui peut être trouvé sur l' échange de pile . IMHO le PO devrait être fermé pour avoir été publié dans le mauvais forum. Il attire actuellement également des réponses d'opinion, mais pas nécessairement, et n'est pas lié à Java d'une manière particulière.
DTO est un modèle et il est indépendant de la mise en œuvre (POJO / POCO). DTO dit, puisque chaque appel à n'importe quelle interface distante est coûteux, la réponse à chaque appel devrait apporter autant de données que possible. Ainsi, si plusieurs requêtes 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 de sorte qu'une seule requête puisse apporter toutes les données requises. Le catalogue des modèles d'architecture d'application d'entreprise contient plus de détails.
Les DTO sont un concept fondamental, non dépassé.
Ce qui est quelque peu dépassé, c'est la notion d'avoir des DTO qui ne contiennent aucune logique, ne sont utilisés que pour transmettre des données et «mappés» à partir des objets du domaine avant la transmission au client, et mappés pour visualiser 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'y ait qu'un seul modèle de données unifié. Pour les applications plus complexes, vous ne souhaitez pas exposer l'ensemble du modèle de domaine au client, un mappage des modèles de domaine vers les 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 obsolète plutôt que tout simplement fausse est que certains frameworks / technologies (principalement plus anciens) l'exigent, car leur domaine et leurs modèles de vue ne sont pas POJOS et sont directement liés au framework.
Plus particulièrement, les Entity Beans dans J2EE avant la norme EJB 3 n'étaient pas des POJO mais 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 séparée - c'était obligatoire.
Bien que DTO ne soit pas un modèle obsolète, il est souvent appliqué inutilement, ce qui peut le faire paraître obsolète.
Du gourou de Java Adam Bien:
Le modèle le plus utilisé dans la communauté Java Enterprise est le DTO. DTO a été clairement défini comme une solution à un problème de distribution. Le DTO était censé être un conteneur de données à gros grains qui transporte efficacement les données entre les processus (niveaux). ~ Adam Bien
De Martin Fowler:
Les DTO sont appelés objets de transfert de données car leur objectif est de transférer des données lors d'appels distants coûteux. Ils font partie de la mise en œuvre d'une interface à grain grossier dont une interface distante a besoin pour ses performances. Non seulement vous n'en avez pas besoin dans un contexte local, mais ils sont en fait nocifs à la fois parce qu'une API à gros grains est plus difficile à utiliser et parce que vous devez faire tout le travail pour déplacer les données de votre domaine ou couche de source de données vers les DTO. ~ Martin Fowler
Voici un exemple spécifique à Java EE d'une utilisation courante mais incorrecte 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 dans le modèle MVC.
Ainsi, par exemple, disons que vous avez un ManagedBean JSF. 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 ultérieurement converti en entité. J'ai entendu cet objet intermédiaire appelé DTO, mais si vos ManagedBeans et Entities fonctionnent dans la même JVM, il y a peu d'avantages à utiliser le modèle DTO.
De plus, pensez aux annotations Bean Validation (encore une fois, si vous n'êtes pas familier avec Java EE, sachez que Bean Validation est une API pour valider les données). 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 dans la même JVM, il n'est pas nécessaire de prendre en charge ce travail supplémentaire: utilisez simplement les entités.
Le 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:
Il y a un avantage, même s'il est très petit, à avoir une séparation des couches dans votre architecture, et à avoir des objets «se transforment» lorsqu'ils se déplacent à travers les couches. ce découplage vous permet de remplacer n'importe quelle couche de votre logiciel avec un minimum de changement, il suffit de mettre à jour le mappage des champs entre 2 objets et votre ensemble.
Si les 2 objets ont les mêmes membres ... eh bien, c'est à cela que sert Apache Commons BeanUtils.copyProperties ();)
vous n'êtes pas le premier à demander . On dirait un autre terrain de jeu de l'idéologie logicielle. J'ai personnellement utilisé des DTO une fois parce que le magasin les utilisait toujours, mais dans ce cas, la structure était également différente de celle des entités.
Google diff b / w POJO et DTO