Qual è lo scopo di utilizzare DTO (Data Transfer Objects)?

Qual è lo scopo di utilizzare DTO ed è un concetto obsoleto? Uso POJO nel livello di visualizzazione per trasferire e conservare i dati. Questi POJO possono essere considerati un'alternativa ai DTO?

DTO è un modello ed è indipendente dall'implementazione (POJO / POCO). DTO afferma che, poiché ogni chiamata a qualsiasi interfaccia remota è costosa, la risposta a ciascuna chiamata dovrebbe portare quanti più dati possibile. Pertanto, se sono richieste più richieste per portare dati per una determinata attività, i dati da portare possono essere combinati in un DTO in modo che solo una richiesta possa portare tutti i dati richiesti. Il catalogo dei modelli di Enterprise Application Architecture ha maggiori dettagli.

I DTO sono un concetto fondamentale, non obsoleto.

DTO come concetto (oggetti il ​​cui scopo è quello di raccogliere dati da restituire al client dal server) non è certamente obsoleto.

Ciò che è in qualche modo obsoleto è l'idea di avere DTO che non contengono alcuna logica, sono usati solo per trasmettere dati e "mappati" da oggetti di dominio prima della trasmissione al client, e lì mappati per visualizzare i modelli prima di passarli al livello di visualizzazione. Nelle applicazioni semplici, gli oggetti di dominio possono spesso essere riutilizzati direttamente come DTO e passati direttamente al livello di visualizzazione, in modo che esista un solo modello di dati unificato. Per applicazioni più complesse non si desidera esporre l'intero modello di dominio al client, quindi è necessario un mapping dai modelli di dominio ai DTO. Avere un modello di vista separato che duplica i dati dai DTO non ha quasi mai senso.

Tuttavia, la ragione per cui questa nozione è obsoleta piuttosto che semplicemente sbagliata è che alcuni framework / tecnologie (principalmente più vecchi) lo richiedono, poiché i loro modelli di dominio e visualizzazione non sono POJOS e sono invece direttamente collegati al framework.

In particolare, Entity Beans in J2EE prima dello standard EJB 3 non erano POJO e invece erano oggetti proxy costruiti dal server delle app - semplicemente non era possibile inviarli al client, quindi non avevi scelta di avere un livello DTO separato - era obbligatorio.

Sebbene DTO non sia un modello obsoleto, viene spesso applicato inutilmente, il che potrebbe far sembrare obsoleto.

Il modello più abusato nella comunità Java Enterprise è il DTO. DTO è stato chiaramente definito come una soluzione per un problema di distribuzione. DTO doveva essere un contenitore di dati a grana grossa che trasportava in modo efficiente i dati tra processi (livelli). ~ Adam Bien

Ad esempio, supponiamo che tu abbia un JSF ManagedBean. Una domanda comune è se il bean deve contenere direttamente un riferimento a un'entità JPA o se deve mantenere un riferimento a un oggetto intermedio che viene successivamente convertito in un'entità. Ho sentito questo oggetto intermedio indicato come DTO, ma se i tuoi ManagedBeans ed Entity operano all'interno della stessa JVM, allora ci sono pochi vantaggi nell'utilizzare il modello DTO.

Prendi in considerazione le annotazioni di convalida del bean. Le tue entità JPA sono probabilmente annotate con convalide @NotNull e @Size. Se stai utilizzando un DTO, ti consigliamo di ripetere queste convalide nel tuo DTO in modo che i client che utilizzano la tua interfaccia remota non debbano inviare un messaggio per scoprire che hanno fallito la convalida di base. Immagina tutto quel lavoro extra di copia delle annotazioni di convalida del fagiolo tra il tuo DTO ed Entità, ma se la tua vista e le entità operano all'interno della stessa JVM, non è necessario intraprendere questo lavoro extra: basta usare le entità.

Il link di IAmTheDude al Catalog of Patterns of Enterprise Application Architecture fornisce una concisa spiegazione dei DTO, e qui ci sono altri riferimenti che ho trovato illuminanti:

• COME AFFARE CON J2EE E DISEGNI DI DESIGN
• Come usare DTO in JSF + Spring + Hibernate
• Pro e contro degli oggetti di trasferimento dati

Assolutamente no! Di recente ho imparato lezioni su come utilizzare meglio i DTO piuttosto che l'oggetto di business che usi (possibilmente associato al tuo mappatore ORM).

Tuttavia, basta usarli quando sono appropriati da usare e non solo per il gusto di usarli perché sono menzionati in un buon libro di schemi.
Un tipico esempio che mi viene in mente è quando esponi una sorta di interfaccia a terze parti. In tale scenario ti piacerebbe mantenere gli oggetti scambiati abbastanza stabili che di solito puoi ottenere bene con i DTO.

Un posto che ho trovato particolarmente utili nei DTO è il contenimento della logica per le risposte API. Con questo modello è facile gestire diversi tipi di risposte dagli oggetti ai vari formati in modo testabile. Usando questo modello nel mio ruolo attuale, siamo stati in grado di iniziare a testare i formati di risposta per le nostre API, il che è stato prezioso poiché il nostro stack sta diventando più isomorfo con vari client (http / mobile). Sicuramente non obsoleto.