DTO = ViewModel?

Sto usando NHibernate per rendere persistenti i miei oggetti di dominio. Per semplificare le cose, sto usando un progetto ASP.NET MVC sia come livello di presentazione che come livello di servizio.

Voglio restituire i miei oggetti di dominio in XML dalle mie classi controller. Dopo aver letto alcuni post qui su Stack Overflow, ho capito che i DTO sono la strada da percorrere. Tuttavia, mi sono anche imbattuto in post che parlano di ViewModel.

La mia domanda: Data Transfer Objects e ViewModels sono la stessa cosa? Oppure un ViewModel è una sorta di sotto-pattern di un DTO?

La definizione canonica di un DTO è la forma dei dati di un oggetto senza alcun comportamento.

ViewModels sono il modello della vista. I ViewModels in genere sono dati completi o parziali di uno o più oggetti (o DTO) più eventuali membri aggiuntivi specifici del comportamento della vista (metodi che possono essere eseguiti dalla vista, proprietà per indicare come alternare gli elementi della vista, ecc ...). Puoi guardare il viewmodel come tutti i dati per una vista più i comportamenti. ViewModels può o meno mappare uno a uno a oggetti di business o DTO.

A proposito, le proiezioni NHibernate sono utili se un certo viewmodel necessita di un sottoinsieme di dati da un oggetto persistente.

ViewModel in ASP.NET La pratica MVC è la stessa del DTO, tuttavia ViewModel nel pattern MVVM è diverso da DTO perché ViewModel in MVVM ha comportamenti ma DTO no.

DTO! = ViewModel

Nel pattern MVVM il ViewModel viene utilizzato per isolare il modello dalla vista. Per rappresentare il Modello si potrebbero usare semplici classi DTO , che ancora una volta è mappato ad un database attraverso es. NHibernate. Ma non ho mai visto una classe ViewModel modellata come un DTO .. ​​Le classi ViewModel hanno principalmente un comportamento, che i DTO non hanno.

DTO - Gli oggetti di trasferimento dati sono esattamente come si dice, contenitori per il trasferimento dei dati. Non hanno alcun comportamento ma solo un gruppo di setter e getter. Alcune persone li rendono immutabili e ne creano di nuovi quando necessario invece di aggiornare quelli esistenti. Dovrebbero essere serializzabili per consentire il trasferimento attraverso il filo.

Generalmente i DTO vengono utilizzati per inviare i dati da un livello a un altro attraverso i limiti del processo poiché le chiamate a un servizio remoto possono essere costose, quindi tutti i dati richiesti vengono inseriti in un DTO e trasferiti al client in un blocco (a grana grossa).

Tuttavia, alcune persone usano la nozione di DTO vincolati a schermo (niente a che fare con l'attraversamento dei confini del processo). Anche in questo caso questi vengono popolati con i dati richiesti (generalmente i dati richiesti per una particolare schermata e potrebbero essere un'aggregazione di dati provenienti da varie fonti) e inviati al client.

http://blog.jpboodhoo.com/CommentView,guid,21fe23e7-e42c-48d8-8871-86e65bcc9a50.aspx

In casi semplici come è già stato detto questo DTO può essere utilizzato per l'associazione alla vista ma nei casi più complessi richiederebbe la creazione di un ViewModel e lo scarico dei dati da DTO a ViewModel che è ovviamente più lavoro (quando si applica il pattern MVVM) .

Quindi, ancora una volta, come già affermato DTO! = ViewModel

e

DTO e ViewModel hanno scopi diversi nella vita

Innanzitutto, la differenza principale è che ViewModel può avere comportamenti o metodi che DTO non deve fare !!!

In secondo luogo, l'utilizzo di DTO come ViewModel in ASP.NET MVC rende l'applicazione strettamente collegata a DTO e questo è esattamente lo scopo opposto dell'utilizzo di DTO. Se lo fai, qual è la differenza utilizzando il tuo modello di dominio o DTO, maggiore complessità per ottenere un anti-pattern?

Anche ViewModel in ASP.NET può utilizzare DataAnnotations per la convalida.

Lo stesso DTO può avere differenti ViewModels Mapping e un ViewModel può essere composto da differenti DTO (sempre con mappatura oggetti non composizione). perché penso che sia anche peggio se hai un ViewModel che contiene un DTO, avremo lo stesso problema.

Dal tuo livello di presentazione, pensa a DTO come a un contratto, riceverai un oggetto che devi considerare estraneo alla tua applicazione e non hai alcun controllo su di esso (anche se hai ex il servizio, il dto e i livelli di presentazione sono tuoi).

Infine, se esegui questa separazione netta, gli sviluppatori possono lavorare insieme con facilità. La persona che progetta ViewModels, Views e Controller non deve preoccuparsi del livello di servizio o dell'implementazione DTO perché eseguirà la mappatura quando gli altri sviluppatori finiranno la loro implementazione ... Può persino utilizzare lo strumento Mocking o il mocking manuale per riempire il livello di presentazione con i dati per il test.

Per alcune viste semplici userò il mio DTO come modelli, ma man mano che le viste diventano più complesse creerò ViewModels.

Per me è un equilibrio tra rapidità (usando DTO, dato che li ho già) e flessibilità (creare ViewModels significa più separazione delle preoccupazioni).

Se utilizzerai DTO come ViewModel, significa che stai facendo un'elevata dipendenza da DTO a causa di qualche motivo per cui stai cambiando DTO, quindi potrebbe avere un impatto su ViewModel.

Usa meglio DTO e converti in viewmodel.

Possiamo usare DTOuguale alla classe Model e possiamo usare viewmodel quando abbiamo bisogno di mostrare / usare più dati / proprietà di modelli in una singola vista. Esempio: creo prima un modello utilizzando il database del framework di entità. Quindi, ora tutto il modello viene generato in base al database. e ora abbiamo bisogno dell'annotazione dei dati, per quelle annotazioni dei dati possiamo creare un nome di cartella DTO, In questa cartella DTO, possiamo mantenere esatti tutti i modelli che già generano e aggiungere l'annotazione dei dati sopra la proprietà. Quindi possiamo usare qualsiasi operazione (usa controller, viste) usando queste classi DTO. E quando abbiamo bisogno di una vista complessa, voglio dire quando abbiamo bisogno di più dati di classi in una vista, possiamo usare viewmodel. Per viewmodel possiamo creare un nome di cartella viewmodel, quindi creare una classe personalizzata e mantenere quella proprietà di cui abbiamo bisogno. Ho provato a chiarirmi. Qualsiasi suggerimento molto apprezzato.