Pourquoi les objets de transfert de données (DTO) sont-ils un anti-modèle?

Question

J'ai récemment entendu des gens dire que les objets de transfert de données (DTO) sont un anti-motif .

Pourquoi? Quelles sont les alternatives?

Answer 1

Certains projets contiennent toutes les données deux fois . Une fois en tant qu'objets de domaine et une fois en tant qu'objets de transfert de données.

Cette duplication ayant un coût énorme , l'architecture doit donc tirer un avantage considérable de cette séparation pour en valoir la peine.

Answer 2

Les DTO ne sont pas un anti-motif. Lorsque vous envoyez des données de bout en bout (par exemple, à une page Web dans un appel Ajax), vous voulez être sûr de conserver la bande passante en envoyant uniquement les données que la destination utilisera. De plus, il est souvent pratique pour la couche de présentation d’avoir les 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 liée à Java, mais dans les langages .NET, les types anonymes, la sérialisation et LINQ permettent de créer des DTO à la volée, ce qui réduit leur configuration et leur utilisation.

Answer 3

DTO un anti-modèle dans EJB 3.0 dit:

  

La nature lourde de l'entité   Haricots dans les spécifications EJB avant   EJB 3.0, a entraîné l'utilisation de   modèles de conception comme le transfert de données   Objets (DTO). DTO est devenu le   objets légers (qui devraient avoir   été l'entité se haricots dans   la première place), utilisé pour envoyer le   données à travers les niveaux ... maintenant EJB 3.0   spec rend le modèle de bean Entity identique   en tant qu'objet Java normal ancien (POJO). Avec   ce nouveau modèle de POJO, vous ne   plus besoin de créer un DTO pour chaque   entité ou pour un ensemble d'entités ... Si   vous voulez envoyer les entités EJB 3.0   à travers le niveau les rendent juste   implémenter java.io.Serialiazable

Answer 4

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 cite l’explosion de DTO:

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

Il existe également un certain nombre d'abus d'ODT mentionnés:

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

Ils ont été créés à partir de systèmes à trois niveaux (utilisant généralement la technologie EJB) 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 vue simplifiée alternative utilisant des POJO comme objets de domaine (souvent annotés avec JPA, etc.) dans un seul niveau ... L'utilisation de DTO ici n'est pas nécessaire.

Answer 5

Les puristes OO diraient que DTO est anti-modèle parce que les objets deviennent des représentations de table de données plutôt que des objets de domaine réels.

Answer 6

Certains considèrent les DTO comme un anti-modèle en raison de leurs éventuels abus. Ils sont souvent utilisés quand ils ne devraient pas être / ne doivent pas l'être.

Cet article décrit vaguement certains abus.

Answer 7

Si vous construisez un système distribué, les DTO ne sont certainement pas un modèle anti-modèle. Tout le monde ne se développera pas dans ce sens, mais si vous avez (par exemple) une application Open Social qui exécute tous JavaScript.

Il publiera une charge de données sur votre API. Ceci est ensuite désérialisé en une forme d'objet, généralement un objet DTO / Request. Ceci peut ensuite être validé pour s'assurer que les données saisies sont correctes avant d'être converties en objet de 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 distribué, il est probable que vous n'en avez pas besoin.

Answer 8

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

Si vous ne créez pas de DTO, vous aurez des objets inutiles transférés de votre couche de gestion à votre couche client / Web.

Pour limiter les frais généraux dans ce cas, transférez plutôt les DTO.

Answer 9

L'intention d'un objet de transfert de données est de stocker des données provenant de différentes sources, puis de les transférer. en une seule fois dans une base de données (ou Façade distante ).

Cependant, le modèle DTO enfreint le principe de responsabilité unique . , car le DTO stocke non seulement des données, mais les transfère également de ou vers la base de données / façade.

La nécessité de séparer les objets de données des objets métier n'est pas un anti-modèle, car il est probablement nécessaire de sépare quand même la couche de base de données .

Au lieu des DTO, vous devriez utiliser les modèles d'agrégation et de référentiel, qui séparent la collection d'objets ( Aggregate ) et le transfert de données ( Référentiel ).

Pour transférer un groupe d'objets, vous pouvez utiliser le modèle Unité de travail , qui contient un ensemble de référentiels et un contexte de transaction; afin de transférer chaque objet de l'agrégat séparément dans la transaction.

Answer 10

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

Définitivement, il s’agit d’un anti-modèle lorsque le seul résultat de son utilisation est un coût plus élevé - au moment de l’exécution ou de la maintenance. J'ai travaillé sur des projets comportant des centaines de DTO identiques aux classes d'entité de base de données. Chaque fois que vous vouliez ajouter un seul champ, vous deviez ajouter un identifiant, par exemple quatre fois - DTO, entité, conversion de DTO en classes ou entités de domaine, conversion inverse, ... Vous avez oublié certains lieux et données inconsistant.

Ce n'est pas un anti-modèle lorsque vous avez vraiment besoin d'une représentation différente des classes de domaine : plus plate, plus riche, plus étroite, ...

Personnellement, je commence avec la classe de domaine et la transmet, avec un contrôle approprié aux bons endroits. Je peux annoter et / ou ajouter des "aide". des classes pour faire des mappages, des bases de données, des formats de sérialisation tels que JSON ou XML ... Je peux toujours scinder une classe en deux si le besoin s'en fait sentir.

Cela concerne votre point de vue - je préfère regarder un objet de domaine comme un seul objet jouant plusieurs rôles, plutôt que plusieurs objets créés les uns des autres. Si le seul rôle d’un objet est de transporter des données, c’est DTO.

Answer 11

Je pense que les gens pensent que cela pourrait être un anti-motif si vous implémentiez tous les objets distants en tant que DTO. Un DTO est simplement un ensemble d'attributs. Si vous avez de gros objets, vous transférez toujours tous les attributs, même si vous n'en avez pas besoin ou que vous ne les utilisez pas. Dans ce dernier cas, préférez utiliser un modèle de proxy.