Qual è il punto di un DTO (Data Transfer Object)?

Question

Perché dovrei usare DTO/oggetti Dominio quando posso semplicemente mettere tutte le classi di business in una libreria di classi, usarle nella logica di business, quindi anche passare quegli stessi oggetti di business alle classi di limite?

AGGIORNAMENTO: Tutti sono ottimi punti, grazie per l'aiuto. Una domanda successiva:

Dove solitamente si collocano questi DTO? Accanto agli oggetti Dominio, ad esempio nello stesso spazio dei nomi?

namespace MedSched.Medical 
{ 
    public class MedicalGroup 
    { 
     //... 
    } 

    public class MedicalGroupDTO 
    { 
     //... 
    } 
} 

Answer 1

• Il DTO fornire un livello di astrazione per il vostro modello di dominio. È quindi possibile modificare il modello e non rompere il contratto che si ha per i clienti del servizio. Questo è simile a una pratica comune nella progettazione di database in cui le viste e le procedure diventano il livello di astrazione per il modello di dati sottostante.
• Serializzazione: è possibile esporre i dati e inviare messaggi sovraccarichi sul filo. Questo può essere mitigato usando gli attributi di serializzazione, ma potresti avere ancora informazioni extra.
• Contratti impliciti e espliciti: esponendo gli oggetti del dominio si lascia al client l'interpretazione del loro utilizzo poiché non hanno a disposizione il modello completo. Spesso si apportano aggiornamenti agli oggetti del dominio implicitamente in base alla presenza o alla rimozione di associazioni o si accettano ciecamente tutte le modifiche. I DTO esprimono esplicitamente l'utilizzo del servizio e l'operazione desiderata.
• disconnessi scenari - vista messaggi espliciti o DTOs renderebbe più facile per voi di implementare modelli di messaggistica e messaggistica come Message Broker, ecc
• DDD - pura DDD richiede che gli oggetti di dominio sono esternamente immutabili, e quindi è necessario scaricare questo a un altro oggetto, tipicamente un DTO.

Answer 2

I DTO sono oggetti di trasferimento dati, con Trasferimento parola chiave. Sono fantastici quando si desidera passare i propri oggetti attraverso il filo e potenzialmente comunicare con una lingua diversa perché sono "leggeri" (ovvero senza logica aziendale)

Se l'applicazione non è basata sul servizio Web, i DTO non sono ti farò davvero qualcosa.

Pertanto, la decisione di utilizzare o non utilizzare DTO deve essere basata sull'architettura dell'applicazione.

Answer 3

Ci sono momenti in cui i dati che si desidera passare non corrispondono esattamente alla struttura degli oggetti di business, nel qual caso si utilizzano DTO.

Es: quando si desidera passare un sottoinsieme di dati o una proiezione.

Answer 4

posso pensare di 2 scenari di base per l'utilizzo di DTOs:

• Stai creando il vostro oggetto di business dai dati che è incompleto e non riuscirà convalida. Ad esempio, si sta analizzando un file CSV o un file Excel da cui viene creato l'oggetto business. Se si utilizzano i dati direttamente da questi oggetti per creare il proprio oggetto business, è possibile che diverse regole di validazione falliscano all'interno dell'oggetto, poiché i dati di tali file sono soggetti a errori. Tendono anche ad avere una struttura diversa che hai nel tuo oggetto business finale: avere un segnaposto per quei dati incompleti sarà utile.

• Stai trasportando il tuo oggetto aziendale tramite un mezzo con larghezza di banda intensiva. Se si utilizza un servizio Web, sarà necessario utilizzare DTO per semplificare l'oggetto prima del trasporto; altrimenti il ​​CLR avrà difficoltà a cercare di serializzare tutti i dati.