ViewModels and rendering

Question

In diversi progetti di esempio, ho visto ViewModels in uso per convertire oggetti di dati in stringhe, da utilizzare nella vista.

In genere, il ViewModel dispone di un costruttore che riceve un parametro - un oggetto dati. Il costruttore compilerà quindi varie proprietà del ViewModel (principalmente stringhe e int).

Ciò impedisce la presenza di qualsiasi logica complessa nella vista.

A prima vista, questa mi sembra una buona idea, poiché impone più completamente la separazione della Vista da una logica complessa.

Ad esempio, supponiamo che la mia vista stia cercando di rendere una proprietà 'Size' di un oggetto dati, essendo Size un numero compreso tra 1 e 3 che rappresenta 'Small/Medium/Large'.

Invece di avere un'istruzione if/switch nella mia vista, avrei solo un 'SizeString' o qualcosa di simile nel mio ViewModel, e l'istruzione if/switch andrebbe nel costruttore ViewModel.

Qualcuno non è d'accordo con questo approccio?

Sarebbe meglio utilizzare qualche altro approccio, come gli helper? E se sì, perché?

Answer 1

Lo scopo del ViewModel è quello di rappresentare (una parte del) modello di dominio complesso scomposto come primitive che possono essere renderizzate in una forma diversa dall'altra.

Questa scomposizione deve avvenire da qualche parte. Può comportare qualche semplice tipo di logica, come il mio esempio preferito: la conversione di un valore discreto (OK, avvertimento, errore) nei colori (verde, giallo, rosso). Questo è l'essenza di ciò che fa un ViewModel, quindi il mio approccio predefinito sarebbe incapsulare questa logica nel ViewModel stesso.

Considerare l'alternativa: se non è implementato in ViewModel, allora dove? Se si mette la logica da qualche altra parte, si finisce con un ViewModel che è fondamentalmente solo una struttura senza logica. Lasciando un ViewModel incapsulare la trasformazione/decomposizione di un oggetto dominio si adatta bene allo Single Responsibility Principle.

Sebbene questo sia il mio approccio predefinito, sono sempre consapevole che la logica potrebbe dover essere riutilizzata su più ViewModels. In questi casi, questa potrebbe essere un'indicazione che il ViewModel originale è in realtà un ViewModel complesso costituito da diverse sottoview. In questi casi, è possibile estrarre la logica comune in un sub-ViewModel che incapsula solo quella piccola parte.

Answer 2

Converte tutto in stringa perché tutto nel web è una stringa.

Fondamentalmente - il modello di vista dovrebbe essere nello stato 'pronto per l'uscita'. Se la rete fosse composta solo da numeri, trasformeremmo tutto in interi/decimali.

Punto intero viewModel: per formattare i dati rappresentabili. Nel tuo caso - dimensione enum a piccola/media/grande. Non è che la logica di distacco dalle viste rende questo prezioso - è la capacità di adept tuoi dati per il web in un modo, un posto.

---

Rispondere a commentare =>

Sì, che si trova bene. Sto facendo lo stesso. Ma cosa dire - non sono contrario a metterlo in discussione. Perché le visualizzazioni e i modelli di visualizzazione sono l'ultimo nella "catena di dipendenze". Sono piuttosto pragmatico e completamente contro solo le situazioni in cui lo sviluppatore utilizza il modello di dominio come modello di visualizzazione ei requisiti per il modello di visualizzazione entrano in conflitto con il modello di dominio (ad esempio quando lo sviluppatore aggiunge nuovi "oggetti dominio" solo a scopo di rappresentazione).