Pourquoi les objects de transfert de données (DTO) sont-ils un anti-pattern?

Certains projets ont toutes les données deux fois . Une fois en tant qu’objects de domaine et une fois en tant qu’objects de transfert de données.

Ce dédoublement a un coût énorme , de sorte que l’architecture doit tirer un énorme bénéfice de cette séparation pour en valoir la peine.

Les DTO ne sont pas un anti-pattern. Lorsque vous envoyez des données sur le réseau (par exemple, sur une page Web dans un appel Ajax), vous voulez vous assurer de conserver la bande passante en envoyant uniquement des données que la destination utilisera. En outre, il est souvent utile que la couche de présentation dispose des données dans un format légèrement différent de celui d’un object métier natif.

Je sais que c’est 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 leur utilisation et leur configuration.

DTO un AntiPattern dans EJB 3.0 dit:

La nature lourde des Entity Beans dans les spécifications EJB antérieures à EJB 3.0 a entraîné l’utilisation de modèles de conception tels que les objects DTO (Data Transfer Objects). Les DTO sont devenus des objects légers (qui auraient dû être les beans entité eux-mêmes en premier lieu), utilisés pour envoyer les données à travers les niveaux … maintenant la spécification EJB 3.0 rend le modèle Entity bean identique à un object POJO. Avec ce nouveau modèle POJO, vous n’aurez plus besoin de créer un DTO pour chaque entité ou pour un ensemble d’entités … Si vous souhaitez envoyer les entités EJB 3.0 à travers le niveau, faites en sorte qu’elles implémentent simplement java.io.Serialiazable

Je ne pense pas que les DTO soient un anti-modèle en soi, mais il existe des antipatternes associés à l’utilisation des DTO. Bill Dudney se réfère à l’explosion de DTO comme exemple:

http://www.softwaresummit.com/2003/speakers/DudneyJ2EEAntiPatterns.pdf

Il y a aussi un certain nombre d’abus des DTO mentionnés ici:

http://anirudhvyas.com/root/2008/04/19/abuses-of-dto-pattern-in-java-world/

Ils proviennent de systèmes à trois niveaux (utilisant généralement EJB comme technologie) comme moyen de transmettre des données entre les niveaux. La plupart des systèmes Java modernes basés sur des frameworks tels que Spring adoptent une autre vue simplifiée en utilisant des POJO comme objects de domaine (souvent annotés avec JPA, etc.) dans un seul niveau … L’utilisation des DTO est inutile.

Les puristes OO diraient que DTO est anti-pattern car les objects deviennent des représentations de tables de données au lieu d’objects réels du domaine.

Certains considèrent les DTO comme un anti-pattern en raison de leurs abus possibles. Ils sont souvent utilisés quand ils ne devraient pas être / n’ont pas besoin d’être.

Cet article décrit vaguement certains abus.

Si vous construisez un système dissortingbué, les DTO ne sont certainement pas un anti-pattern. Tout le monde ne se développera pas en ce sens, mais si vous avez une application Open Social (par exemple), tout fonctionne en JavaScript.

Il publiera un chargement de données sur votre API. Ceci est ensuite désérialisé en une forme d’object, généralement un object DTO / Request. Cela peut ensuite être validé pour garantir que les données saisies sont correctes avant d’être converties en object modèle.

À mon avis, c’est considéré comme un anti-modèle parce qu’il est mal utilisé. Si vous ne construisez pas un système dissortingbué, il y a de fortes chances que vous n’en ayez pas besoin.

DTO devient une nécessité et non un ANTI-PATTERN lorsque tous vos objects de domaine chargent des objects associés EAGERly.

Si vous ne faites pas de DTO, vous aurez des objects transférés inutiles de votre couche de gestion sur votre couche client / Web.

Pour limiter la surcharge pour ce cas, transférez plutôt les DTO.

L’intention d’un object de transfert de données est de stocker des données provenant de différentes sources, puis de les transférer dans une firebase database (ou une façade distante ).

Cependant, le modèle DTO viole le principe de la responsabilité unique , puisque le DTO non seulement stocke les données, mais les transfère également de ou vers la firebase database / façade.

La nécessité de séparer les objects de données des objects métier n’est pas un anti-modèle, car il est probablement nécessaire de séparer la couche de firebase database .

Au lieu des DTO, vous devez utiliser les modèles d’agrégation et de référentiel, qui séparent la collection d’objects ( agrégat ) et le transfert de données ( référentiel ).

Pour transférer un groupe d’objects, vous pouvez utiliser le modèle Unit Of Work , qui contient un ensemble de référentiels et un contexte de transaction. afin de transférer chaque object dans l’agrégat séparément dans la transaction.

Je pense que les gens veulent dire que cela pourrait être un anti-pattern si vous implémentez tous les objects distants en tant que DTO. Un DTO est simplement un ensemble d’atsortingbuts et si vous avez de gros objects, vous transférez toujours tous les atsortingbuts, même si vous n’en avez pas besoin ou que vous ne les utilisez pas. Dans le dernier cas, préférez utiliser un modèle de proxy.

La question ne devrait pas être “pourquoi”, mais ” quand “.

En définitive, il est anti-pattern lorsque son utilisation a pour seul résultat un coût plus élevé : runtime ou maintenance. J’ai travaillé sur des projets ayant des centaines de DTO identiques aux classes d’entités de firebase database. Chaque fois que vous vouliez append un seul champ que vous souhaitiez append comme quatre fois – à DTO, à l’entité, à la conversion de DTO en classes ou entités de domaine, la conversion inverse, … Vous avez oublié certains endroits et données inconsistant.

Ce n’est pas un anti-pattern quand vous avez vraiment besoin d’une représentation différente des classes de domaine – plus plat, plus riche, plus étroit, …

Personnellement, je commence avec la classe de domaine et la transmet, avec une vérification correcte aux bons endroits. Je peux annoter et / ou append des classes “helper” pour créer des mappages, des bases de données, des formats de sérialisation comme JSON ou XML … Je peux toujours diviser une classe en deux si j’en ai le besoin.

Il s’agit de votre sharepoint vue – je préfère regarder un object de domaine comme un object unique jouant différents rôles, au lieu de plusieurs objects créés les uns des autres. Si le seul rôle d’un object est de transporter des données, alors c’est DTO.