Fabriziog ha scritto:
Ho visto a che serve un ViewModel e, se non ho capito male, aiuta a velocizzare la visualizzazione in caso di tabelle complesse.
La finalità dei
ViewModel è quello di agevolare il passaggio di dati dal Controller alla View, creando un apposito contenitore nel quale immagazzinare in modo strutturato e congeniale le informazioni che la vista dovrà poi andare a prendere per riportarle all'interno di una pagina, di un file o altro.
Un
ViewModel andrebbe creato ogni volta che può far comodo, soprattutto quando può evitare o ridurre ulteriormente il codice inserito nella View, perché la vista tendenzialmente è l'unico elemento non testabile in modo automatizzato del progetto, quindi dovrebbe contenere solo codice con complessità 1 (es. niente
if(), niente
switch(), ecc.).
Quindi, non fare caso alla complessità della tabella, ma valuta il codice della vista e sposta nel
ViewModel tutto il possibile.
Ad esempio, supponiamo che la vista debba riportare la stessa lista di elementi ma ordinata in due modi diversi: crea un ViewModel da inizializzare con gli elementi di partenza e aggiungi due metodi che ti restituiscano gli stessi elementi con i diversi ordinamenti applicati da mostrare nella pagina. Oppure, mettiamo che tu debba applicare una formattazione particolare ad alcuni valori di una vista specifica: invece di ridondare il codice o scriverlo nella vista, inseriscilo nel ViewModel e richiamalo dalla vista stessa.
E' chiaro che se le funzionalità inserite nel ViewModel possono essere utili altrove (es. formattazione di date con un certo formato o altre feature condivisibili), allora dovrebbero stare invece in un altro contenitore, o in una
Class Library dedicata, in modo da poter essere accessibili ovunque serva.
Fabriziog ha scritto:
Ora, siccome questa è l'unica tabella complessa di tutto il corso, mi chiedo come riesco a valutare la complessità di una tabella.
E' semplice: non usare quel criterio. Io ad esempio il ViewModel lo creo sempre: in questo modo, non ho mai ostacoli futuri a qualsiasi necessità di introdurre al suo interno nuovi dati e/o funzionalità, sollevandomi dalla necessità di andare a modificare in seguito sia il Controller che la View.
Fabriziog ha scritto:
Per questa tabella è stato seguito un approccio differente rispetto a quelli seguiti finora.
[...]
E poiché il corso non lo spiega (o forse sono io che non l'ho capito) non riesco a capire se questo è un approccio differente oppure in caso di presenza di ViewModel questo è il codice da utilizzare.
Più che un approccio differente, se ho capito bene il codice, mi pare solo che ci si trovi in presenza di uno scenario dove l'operazione di riferimento debba inserire contestualmente più record su tabelle correlate, da cui la parte di codice aggiuntiva (o più complessa, all'apparenza).
La logica da implementare dipende dalla quantità e dal tipo di dati da trattare. Non dipende dal ViewModel, sia perché il ViewModel potrebbe essere creato in seguito, sia perché le due parti sono disgiunte: la logica del Controller o del Model, a seconda di dove la si vuole collocare, gestiscono la "business logic" del sistema, mentre il ViewModel fa solo da aggregatore e da supporto al veicolare alcune informazioni verso le viste, o dalle viste (se prendiamo in considerazione anche il meccanismo di
Model Binding, ossia della capacità di ASP.NET di compilare un ViewModel con i dati provenienti da un
<form>).
Ciao!