A che serve utilizzare DTO ed è un concetto obsoleto? Io uso POJO s nel livello vista per trasferire e conservare i dati. Questi POJO possono essere considerati un'alternativa ai DTO?
DTO è un modello ed è indipendente (POJO / POCO). DTO dice, dal momento che ogni chiamata a qualsiasi interfaccia remota è costosa, la risposta ad ogni chiamata dovrebbe portare quanti più dati possibili. Quindi, se sono richieste più richieste per portare dati per una particolare attività, i dati da portare possono essere combinati in un DTO in modo che solo una richiesta possa portare tutti i dati richiesti. Catalogo dei modelli di Enterprise Application Architecture ha maggiori dettagli.
Le DTO sono un concetto fondamentale, non superato.
DTO come concetto (oggetti il cui scopo è raccogliere dati da restituire al client dal server) non è certamente obsoleto.
Ciò che è un po 'antiquato è la nozione di avere DTO che non contengono alcuna logica, sono usati solo per trasmettere dati e "mappati" da oggetti di dominio prima della trasmissione a il client, e lì mappato per visualizzare i modelli prima di passarli al livello di visualizzazione. Nelle applicazioni semplici, gli oggetti dominio possono spesso essere riutilizzati direttamente come DTO e passati direttamente al livello di visualizzazione, in modo che ci sia un solo modello di dati unificato. Per applicazioni più complesse non si desidera esporre l'intero modello di dominio al client, quindi è necessaria una mappatura da modelli di dominio a DTO. Un modello di vista separato che duplica i dati dal DTO non ha quasi mai senso.
Tuttavia, il motivo per cui questa nozione è superata piuttosto che semplicemente errata è che alcuni framework / tecnologie (soprattutto più vecchi) lo richiedono, poiché i loro domini e modelli di visualizzazione non sono POJOS e sono invece direttamente collegati al framework.
In particolare, gli Entity Beans in J2EE prima dello standard EJB 3 non erano POJO e invece erano oggetti proxy costruiti dal server dell'app - semplicemente non era possibile inviarli al client, quindi non avevi scelta riguardo al fatto di avere un strato DTO separato: era obbligatorio.
Sebbene DTO non sia uno schema obsoleto, viene spesso applicato inutilmente, il che potrebbe renderlo obsoleto.
The most misused pattern in the Java Enterprise community is the DTO. DTO was clearly defined as a solution for a distribution problem. DTO was meant to be a coarse-grained data container which efficiently transports data between processes (tiers). ~ Adam Bien
Ad esempio, supponiamo di avere un bean gestito da JSF. Una domanda comune è se il bean deve tenere un riferimento a un'entità JPA direttamente, o dovrebbe mantenere un riferimento ad un oggetto intermedio che viene successivamente convertito in un'entità. Ho sentito questo oggetto intermedio indicato come un DTO, ma se i tuoi ManagedBeans e le Entità operano all'interno della stessa JVM, allora c'è poco beneficio nell'usare il modello DTO.
Prendere in considerazione le annotazioni sulla validazione dei bean. Le tue entità JPA sono probabilmente annotate con convalide @NotNull e @Size. Se si utilizza un DTO, è necessario ripetere queste convalide nel DTO in modo che i client che utilizzano l'interfaccia remota non debbano inviare un messaggio per scoprire di aver fallito la convalida di base. Immagina tutto il lavoro extra di copia delle annotazioni di convalida dei bean tra il tuo DTO e Entity, ma se la tua vista e le entità operano all'interno della stessa JVM, non c'è bisogno di svolgere questo lavoro extra: basta usare le Entità.
Il link di IAmTheDude a Catalogo dei modelli di Enterprise Application Architecture fornisce una spiegazione concisa dei DTO, e qui ci sono più riferimenti I trovato illuminante:
Assolutamente no! Di recente ho lezioni apprese su come utilizzare al meglio gli DTO anziché il tuo oggetto business che usi (eventualmente 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 qualche buon libro di modelli.
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 puoi ottenere normalmente con gli DTO.
Un luogo in cui ho trovato che le DTO sono particolarmente utili è nel contenere la logica per le risposte API. Con questo modello è facile gestire diversi tipi di risposte dagli oggetti ai vari formati in modo verificabile. Usando questo modello nel mio ruolo attuale, siamo stati in grado di iniziare a testare i formati di risposta per le nostre API che sono state preziose dal momento che il nostro stack sta diventando più isomorfo con vari client (http / mobile). Sicuramente non obsoleto.
Leggi altre domande sui tag java design-patterns