2009-09-16 16 views

risposta

71

Hanno lo stesso scopo (incapsulare i dati per un altro livello dell'applicazione) ma lo fanno in modo diverso e per diversi motivi.

  • Lo scopo di un DTO è quello di ridurre il numero di chiamate tra livelli di un'applicazione, specialmente quando tali chiamate sono costosi sistemi (ad esempio distribuiti). Le DTO sono quasi sempre banalmente serializzabili e quasi mai contengono alcun comportamento.

    Ad esempio, stai sviluppando un sito di e-commerce. CreateCustomer e AddCustomerAddress sono operazioni separate a livello di database, ma per motivi di prestazioni si potrebbe voler aggregare i propri dati in un NewCustomerWithAddressDto in modo che il client debba solo effettuare un viaggio di andata e ritorno al server, e non deve preoccuparsi che il il server potrebbe fare un sacco di cose diverse con il pacchetto di dati.

  • Il termine "ViewModel" indica cose leggermente diverse in diversi tipi di MV *, ma il suo scopo è principalmente la separazione delle preoccupazioni. Il tuo modello è spesso ottimizzato per scopi diversi dalla presentazione ed è responsabilità del ViewModel disaccoppiare la tua vista dai dettagli di implementazione del modello. Inoltre, la maggior parte dei modelli MV * consiglia di rendere le tue visualizzazioni "stupide" il più possibile, e quindi il ViewModel a volte si assume la responsabilità della logica di presentazione.

    Ad esempio, nella stessa applicazione di e-Commerce, il tuo CustomerModel è la "forma" sbagliata per la presentazione sulla vista "Nuovo cliente". Per i principianti, la tua vista ha due campi modulo per l'utente per inserire e confermare la password, e il tuo CustomerModel non contiene affatto un campo password! Il tuo NewCustomerViewModel conterrà quei campi e potrebbe, a seconda del tuo gusto di MV *, essere responsabile di alcune logiche di presentazione (ad es. Per mostrare/nascondere parti della vista) e della convalida di base (ad esempio assicurandosi che entrambi i campi della password corrispondano).

+0

Questa è una spiegazione eccellente! Fino ad ora gli unici modelli di visualizzazione che avevo visto avevano solo getter e setter, quindi ero tipo: wow è molto simile a un DTO. Grazie per aver chiarito questo per me. – mkelley33

11

Lo scopo è diverso:

  • DTO sono usati per trasmettere dati
  • ViewModels vengono utilizzate per mostrare i dati a un utente finale.

Quindi normalmente ViewModels contiene i dati di presentazione, in molti casi è simile a quello presente in un DTO, ma con alcune differenze. Pensa alla rappresentazione di enumerazioni, localizzazione, valuta, formati data, .... Questo perché normalmente non dovrebbe esserci alcuna logica nella tua vista.

10

DTOs in MVVM e MVP sono di solito oggetti molto Dumb e sono fondamentalmente solo un mucchio di setter di proprietà e getter. I ViewModels d'altra parte possono avere qualche comportamento.

Un pratico effetto collaterale positivo dell'utilizzo di DTO consente una serializzazione più semplice. Se hai un oggetto piuttosto complesso, ad esempio C#, spesso ti ritrovi a dover disattivare selettivamente le cose che non vuoi serializzare. Questo può diventare piuttosto brutto e DTO semplifica questo processo.

+3

+1, la differenza chiave è che i DTO sono stupidi (e quindi banalmente serializzabili, che è il loro * lavoro *), e ViewModels può contenere la logica che altrimenti sarebbe andata nella tua vista (che è * il loro * lavoro). –

+0

@Igor Zevaka Puoi spiegare cosa intendi per comportamento? –

1

Un modello di vista e un oggetto di trasferimento dati presentano somiglianze e differenze.

analogo: Trasferire i dati in un record (istanza di oggetto, forse serializzati) ad un ricevitore, sia una vista o un servizio

Differenza: una vista del modello è destinato ad essere inviato a una vista, dove sarà visualizzato, con la formattazione. Un modello di vista invia inoltre i dati a un controller. Un DTO di solito non è inteso per la presentazione. È inteso per inviare dati grezzi.

Problemi correlati