J'ai récemment entendu des personnes dire que objets de transfert de données (DTO) sont une anti-modèle .
Pourquoi ? Quelles sont les alternatives ?
Certains projets disposent de toutes les données en double . Une fois en tant qu'objets de domaine et une fois en tant qu'objets de transfert de données.
Le présent la duplication a un coût énorme L'architecture doit donc tirer un avantage considérable de cette séparation pour qu'elle en vaille la peine.
Veuillez préciser ce que vous entendez par "coût énorme". Expliquez également pourquoi ce coût ne peut pas être éliminé en utilisant des techniques de génération de code pour générer les classes DTO.
+1. Deux fois ? Seulement si vous avez de la chance :-) Les projets qui dupliquent les entités de domaine en tant que DTO ont également tendance à avoir presque les mêmes, mais avec des interfaces utilisateur subtilement différentes pour les compléter. Cela fait 3. Et si, à Dieu ne plaise, il y a une sorte de remoting (services web / xml-rpc / quoi que ce soit), vous pouvez facilement atteindre 4 ou 5.
Voyons que le premier coût consiste à les convertir de l'objet de domaine au DataDto. Ensuite, vous convertissez le DataDto en WebDto (ou en UiDto), ce qui représente le deuxième coût. Plus tard, vous devrez ajouter un champ. Vous devez donc ajouter le champ au domaine et aux deux Dtos, ainsi qu'aux routines de conversion. Comme les WebDtos sont souvent des chaînes de caractères, il faut maintenant effectuer des calculs sur un champ numérique. Il faut donc modifier le WebDto et sa routine de conversion. C'est un autre coût. Il y a donc des coûts liés au temps de développement, au temps de débogage et, bien sûr, aux frais généraux des conversions.
Les DTO ne sont pas un anti-modèle. Lorsque vous envoyez des données par câble (par exemple, à une page web dans le cadre d'un appel Ajax), vous voulez vous assurer que vous conservez la bande passante en n'envoyant que les données que la destination utilisera. En outre, il est souvent pratique pour la couche de présentation de disposer des données dans un format légèrement différent de celui d'un objet métier natif.
Je sais qu'il s'agit d'une question orientée Java, mais dans les langages .NET, les types anonymes, la sérialisation et LINQ permettent de construire des DTO à la volée, ce qui réduit la configuration et les frais généraux liés à leur utilisation.
Je vais devoir downvoter cette réponse à cause de votre mention de la sérialisation des types anonymes. Vous ne pouvez même pas retour un type anonyme, et encore moins de le sérialiser de la même manière qu'un DTO.
@John, c'est faux. C'est ce que je fais tout le temps. La sérialisation utilise la réflexion, qui fonctionne parfaitement sur les types anonymes. Il suffit de le passer au sérialiseur en tant qu'objet. Et une fois qu'il est sérialisé (en xml ou json, par exemple), vous pouvez bien sûr le retourner à partir d'une méthode.
John, ce n'est pas vrai. Vous pouvez parfaitement sérialiser des types anonymes en JSON. Essayez-le dans une application MVC : return Json(new { Foo = "Hi there ! } ) ; Je vous promets que cela fonctionne très bien. Mieux, peut-être, que les types non anonymes, puisque les types anonymes n'ont généralement pas de cycles dans leurs graphes d'objets, ce qui casse le sérialiseur JSON.
"DTO an AntiPattern in EJB 3.0" (lien original actuellement hors ligne) dit :
Le poids de l'Entité Beans dans les spécifications EJB antérieures à EJB 3.0, a conduit à l'utilisation de la méthode de de conception tels que les objets de les objets de transfert de données (DTO). Les DTO sont devenus le modèle de conception objets légers (qui auraient dû être les être les entités beans elles-mêmes en les beans eux-mêmes), utilisés pour envoyer les données entre les différents niveaux... Aujourd'hui, la spécification EJB 3.0 rend le modèle de l'Entity Bean identique à celui du que le modèle Plain old Java object (POJO). Avec ce ce nouveau modèle POJO, vous n'aurez plus plus besoin de créer un DTO pour chaque entité ou pour un ensemble d'entités... Si vous voulez envoyer l'EJB vous voulez envoyer les entités EJB 3.0 à travers le niveau, il suffit de leur faire implémenter java.io.Serialiazable
Vrai lorsque vous transférez des objets entre des méthodes de la même JVM, en mémoire. Ce n'est pas le cas lorsque vous sérialisez sur le fil et que vous souhaitez contrôler la profondeur de sérialisation, et/ou préserver le chargement paresseux.
Je ne pense pas que les DTO soient un anti-modèle en soi, mais il existe des anti-modèles associés à l'utilisation des DTO. Bill Dudney fait référence à l'explosion des DTO comme exemple :
http://www.softwaresummit.com/2003/speakers/DudneyJ2EEAntiPatterns.pdf
Un certain nombre d'abus commis par les ODT sont également mentionnés ici :
http://anirudhvyas.com/Root/2008/04/19/abuses-of-dto-pattern-in-java-world/
Ils sont nés des systèmes à trois niveaux (utilisant typiquement la technologie EJB) comme moyen de transmettre des données entre les différents niveaux. La plupart des systèmes Java modernes basés sur des frameworks tels que Spring adoptent un point de vue alternatif simplifié en utilisant les POJO comme objets de domaine (souvent annotés avec JPA etc...) dans un seul niveau... L'utilisation de DTO n'est pas nécessaire ici.
Vous avez tout à fait raison de dire que les DTO sont un bon modèle Les modèles d'évaluation de la qualité de l'eau et de l'air ne sont pas des anti-modèles, lorsqu'ils sont utilisés dans leur contexte approprié. Votre deuxième lien semble mort pour l'instant, mais le plus grand abus que j'ai vu est celui où chaque objet de domaine avait un "DTO" correspondant pour l'interaction avec la base de données, qui n'ajoutait aucune valeur et n'était pas du tout un DTO !
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
14 votes
Peut-être parce que les objets de gestion sont eux-mêmes capables de transporter leurs propres données, merci beaucoup !
18 votes
"Anti-pattern" pourrait bien être mon candidat pour la phrase dont le quart d'heure est écoulé depuis longtemps. C'est un synonyme de "Je ne veux pas m'embêter à justifier ma pensée", comme "Il est bien connu que...".
7 votes
Zoidberg, l'envoi d'objets avec des méthodes par câble nous a donné CORBA, DCOM et d'autres expériences dont j'essaie d'effacer le souvenir. Le problème, c'est que tôt ou tard, les gens veulent appel ces méthodes.
14 votes
Les DTO incarnent le principe DRY, qui malheureusement en J2EE signifie do se répéter.
1 votes
Vous voudrez peut-être lire ceci : L'objet de transfert de données est une honte