Perché gli oggetti di trasferimento dati (DTO) sono un anti-schema?

Question

Di recente ho sentito persone dire che oggetti di trasferimento dati (DTO) sono un anti-modello .

Perché? Quali sono le alternative?

Answer 1

Alcuni progetti hanno tutti i dati due volte . Una volta come oggetti di dominio e una volta come oggetti di trasferimento dati.

Questa duplicazione ha un costo enorme , quindi l'architettura deve trarre un enorme vantaggio da questa separazione per valerne la pena.

Answer 2

I DTO non sono un anti-schema. Quando si inviano alcuni dati attraverso il cavo (ad esempio, a una pagina Web in una chiamata Ajax), si desidera essere sicuri di conservare la larghezza di banda inviando solo i dati che la destinazione utilizzerà. Inoltre, spesso è conveniente che il livello di presentazione abbia i dati in un formato leggermente diverso rispetto a un oggetto business nativo.

So che questa è una domanda orientata a Java, ma nei linguaggi .NET tipi anonimi, serializzazione e LINQ consentono di costruire DTO al volo, il che riduce la configurazione e il sovraccarico del loro utilizzo.

Answer 3

DTO un AntiPattern in EJB 3.0 dice:

  

La natura pesante dell'Entità   Fagioli nelle specifiche EJB precedenti a   EJB 3.0, ha comportato l'utilizzo di   modelli di progettazione come Trasferimento dati   Oggetti (DTO). DTOs divenne il   oggetti leggeri (che dovrebbero avere   stato l'entità stessa fagioli   il primo posto), utilizzato per inviare il file   dati attraverso i livelli ... ora EJB 3.0   spec rende lo stesso modello di bean Entity   come semplice oggetto Java semplice (POJO). Con   questo nuovo modello POJO, no   è più necessario creare un DTO per ciascuno   entità o per un insieme di entità ... Se   si desidera inviare le entità EJB 3.0   attraverso il livello li rendono giusti   implementare java.io.Serialiazable

Answer 4

Non credo che i DTO siano di per sé un anti-pattern, ma ci sono antipattern associati all'utilizzo dei DTO. Bill Dudney fa riferimento all'esplosione DTO come esempio:

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

Vi sono anche numerosi abusi dei DTO menzionati qui:

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

Hanno avuto origine a causa di sistemi a tre livelli (che in genere utilizzano EJB come tecnologia) come mezzo per passare i dati tra i livelli. La maggior parte dei moderni sistemi Java basati su framework come Spring ha una visione alternativa semplificata usando POJO come oggetti di dominio (spesso annotati con JPA ecc ...) in un unico livello ... L'uso dei DTO qui non è necessario.

Answer 5

I puristi di OO direbbero che DTO è anti-pattern perché gli oggetti diventano rappresentazioni di tabelle di dati anziché oggetti di dominio reali.

Answer 6

Alcuni considerano i DTO un anti-modello a causa dei loro possibili abusi. Sono spesso usati quando non dovrebbero essere / non devono essere.

Questo articolo descrive vagamente alcuni abusi.

Answer 7

Se stai costruendo un sistema distribuito, i DTO non sono certamente un modello anti. Non tutti si svilupperanno in questo senso, ma se disponi di un'app Open Social (ad esempio) che esegue JavaScript.

Pubblica un carico di dati nella tua API. Questo viene quindi deserializzato in una forma di oggetto, in genere un oggetto DTO / Request. Questo può quindi essere validato per garantire che i dati inseriti siano corretti prima di essere convertiti in un oggetto modello.

Secondo me, è visto come un anti-pattern perché è usato male. Se non stai costruendo un sistema distribuito, è probabile che non ti servano.

Answer 8

DTO diventa una necessità e non un ANTI-PATTERN quando tutti gli oggetti del tuo dominio caricano EAGERly oggetti associati.

Se non si creano DTO, si avranno oggetti trasferiti non necessari dal livello aziendale al livello client / Web.

Per limitare le spese generali per questo caso, piuttosto trasferire i DTO.

Answer 9

L'intenzione di un Object Data Transfer è di archiviare dati da fonti diverse e quindi trasferire in un database (o Remote Facade ) contemporaneamente.

Tuttavia, il modello DTO viola il Principio di responsabilità singola , poiché il DTO non memorizza solo i dati, ma li trasferisce anche da o verso il database / la facciata.

La necessità di separare gli oggetti dati dagli oggetti business non è un antipattern, poiché è probabilmente necessario separa comunque il livello del database .

Invece di DTO dovresti usare i pattern di aggregazione e repository, che separano la raccolta di oggetti ( Aggregate ) e il trasferimento dei dati ( Repository ).

Per trasferire un gruppo di oggetti è possibile utilizzare il modello Unit Of Work , che contiene un insieme di repository e un contesto di transazione; per trasferire ciascun oggetto nell'aggregato separatamente all'interno della transazione.

Answer 10

La domanda non dovrebbe essere " perché " ;, ma " quando " ;.

Sicuramente è anti-pattern quando solo il risultato dell'uso è un costo più elevato - runtime o manutenzione. Ho lavorato su progetti con centinaia di DTO identici alle classi di entità del database. Ogni volta che desideri aggiungere un singolo campo, aggiungi annunci come quattro volte: a DTO, a entità, a conversione da DTO a classi o entità di dominio, conversione inversa, ... Hai dimenticato alcuni dei luoghi e dei dati ottenuti incoerente.

Non è non anti-pattern quando hai davvero bisogno di una diversa rappresentazione delle classi di dominio : più piatta, più ricca, più stretta, ...

Personalmente inizio con la classe di dominio e la passo in giro, con un controllo adeguato nei posti giusti. Posso annotare e / o aggiungere un po 'di "helper" classi per creare mappature, database, formati di serializzazione come JSON o XML ... Posso sempre dividere una classe in due se ne sento il bisogno.

Riguarda il tuo punto di vista: preferisco guardare un oggetto di dominio come un singolo oggetto che svolge vari ruoli, anziché più oggetti creati l'uno dall'altro. Se l'unico ruolo che un oggetto ha è il trasporto di dati, allora è DTO.

Answer 11

Penso che la gente significhi che potrebbe essere un anti-pattern se si implementano tutti gli oggetti remoti come DTO. Un DTO è semplicemente un insieme di attributi e se si hanno oggetti di grandi dimensioni si trasferiscono sempre tutti gli attributi anche se non sono necessari o non li si utilizza. In quest'ultimo caso preferisci usare un modello Proxy.