Passare dati alle Views

Una View può esistere anche senza un Model o qualsiasi altro tipo di dati preparati dal server, ma nella maggior parte dei casi, avrete sempre bisogno di accedere ai dati resi disponibili da un Controller. Poichè la vostra View non dovrebbe sapere quale controller la sta utilizzando (secondo la regola della separazione dei compiti), il vostro Controller è responsabile che i dati necessari siano disponibili alla View. Ci sono due metodi principali per fare questo: O create un Model e quindi lo passate alla View oppure utilizzate i contenitori ViewData/ViewBag per rendere i dati disponibili alla View. Andiamo ad esaminare questi approcci in dettaglio:

Noterete un po di sovrapposizione nelle informazioni fornite da questo articolo e le informazioni già fornite nella parte di avvio rapido sull'aggiunta di un modello al progetto.

Usare un (View) Model

Poichè questa tecnologia è chiamata MVC (abbreviazione di Model-View-Controller), l'uso di un (View) Model è certamente l'approccio più chiaro e più comune per passare dei dati alla View. Parleremo maggiormente del Model più tardi un questa guida, ma per adesso sappiate che si tratta semplicemente di un oggetto che rappresenta qualcosa dal mondo reale. Incontreremo anche il concetto di "View Model" - e ancora ne discuteremo maggiormente più tardi, ma per descriverlo brevemente, un View Model è solo un Model passato ad una View. Pertanto può essere qualcosa che già esiste nel vostro progetto come per esempio un oggetto User o Product oppure una classe creata appositamente per rappresentare dei dati che desiderate utilizzare all'interno della vostra View.

Un Model non deve comunque essere una classe complessa - in teoria potrebbe essere benissimo qualcosa di molto semplice come una stringa, un numero intero o una variabile DateTime. In altre parole, qualunque cosa disponibile nel framework .NET può essere usata come Model. In pratica però, il vostro Model è di solito una classe composta da almeno un paio di proprietà. Così per esempio, un Model usato per rappresentare un prodotto potrebbe assomigliare a questo:

public class Product
{
    public string Title { get; set; }

    public double Price { get; set; }
}

Il collegamento fra il Model e la View viene realizzato dal Controller - riceve un input dall'utente e restituisce i dati corrispondenti alla View. Per esempio come qui di seguito:

public IActionResult Details(int id)
{
    Product product = new Product()
    {
        Title = "Toilet Paper",
        Price = 1.99
    };
    return View(product);
}

Notate come passiamo una istanza della classe product alla View quando chiamiamo il metodo View(). Nella View Product/Details, ora possiamo definire che la classe Product rappresenta il Model che questa View si aspetta, utilizzando la direttiva @model, che inseriamo all'inizio della View:

@model HelloMVCWorld.Models.Product

Sistemato questo punto, adesso possiamo iniziare ad usare il Model e le sue proprietà all'interno della View:

@model HelloMVCWorld.Models.Product

<h1>@Model.Title</h1>
Price: @Model.Price

Grazie al fatto che abbiamo definito chiaramente il tipo di dati per il Model di questa View adesso possiamo ottenere un aiuto nell'accedere ai membri dell'oggetto grazie ad IntelliSense ed il vostro codice può essere convalidato durante il processo di Build per avere la certezza che usiate solo le property ed i metodi che sono disponibili sull'oggetto Model

Dynamic Views:

Se non dichiarate un tipo per il Model della vostra View usando la direttiva @modele, allora la View non si aspetta che un Model, di qualche tipo specifico, le venga passato. Ma questo non vi impedisce di procedere e di usare comunque l'oggetto. Questo approccio viene chiamato come Dynamic Views e non è utilizzato molto spesso perchè si perdono i benefici del supporto IntelliSense e i controlli al momento della compilazione sulle proprietà utilizzate.

Pertanto, potreste, nell'esepio precedente, togliere la direttiva @model all'inizio della View, e tutto continuerà a funzionare. In questa situazione la property Model sarà considerata come un oggetto dynamic, dove è possibile accedere alle proprietà senza che il compilatore controlli la loro esistenza. Naturalmente, questo significa anche che se cercate di accedere ad un proprietà inesistente, la generazione della pagina fallirà a runtime, generando una eccezzione. Pertanto le Dynamic Views non sono utilizzate molto.

I contenitori ViewData/ViewBag

Come metodo alternativo all'approcio basato sul Model con tipo ben definito per passare dati alla View, potreste utilizzare i cosidetti contenitori ViewData/ViewBag. Potete aggiungere informazioni a questi contenitori e quindi essere automaticamente in grado di accedere ai dati memorizzati in essi dalle vostre Views. In effetti è abbastanza semplice e potete fare quasi le stesse cose come se aveste usato un Model tipizzato. Ecco un esempio:

public IActionResult DetailsViewData(int id)
{
    ViewBag.ProductTitle = "Toilet Paper";
    ViewBag.ProductPrice = 1.99;
    return View();
}

Ora potete accedere a questi dati dalla vostra View molto semplicemente grazie alla sempre disponibile proprietà chiamata ViewBag:

<h1>@ViewBag.ProducTtitle</h1>
Price: @ViewBag.ProductPrice

La differenza più importante qui è che non c'è nessun controllo su queste proprietà al momento della compilazione e nessun aiuto da IntelliSense quando cercherete di utilizzarle. In altre parole potreste facilmente fare un errore di ortografia sul nome di una proprietà e non ci niente a correggervi. Non noterete nulla fino a quando non userete la View. Pertanto è consigliato di utilizzare ViewData/ViewBag solo per piccole parti di dati. Ricordate comunque, che siete liberi di combinare l'uso dei ViewData/ViewBag con una View tradizionale e fortemente tipizzata.

Qual'è la differenza tra ViewData e ViewBag?

Avrete notato che utilizziamo i due termini per gestire dati dinamici. Le proprietà ViewBag e ViewData. Entrambe si riferiscono alla stessa cosa ovvero ad un Dictionary di chiavi e valori (gli oggetti). Comunque la ViewBag è un oggetto DynamicObject che rappresenta il Dictionary e tu permette di accedere ai dati come se fossero proprietà dell'oggetto ViewBag anzichè usare il nome di singole chiavi in un Dictionary. Siete liberi di usare entrambe le properties in modo interscambiabile poichè si riferiscono agli stessi dati. Così per confrontare le due cose ecco un esempio di come funziona utilizzando entrambi gli approcci.

Controller

public IActionResult DetailsViewData(int id)
{
    ViewData["ProductTitle"] = "Toilet Paper";
    ViewBag.ProductPrice = 1.99;
    return View();
}

View

<h1>@ViewData["ProducTtitle"]</h1>
Price: @ViewBag.ProductPrice

Notate come utilizziamo la ViewData e pertanto un approccio basato sul Dictionary per leggere e scrivere il ProductTitle, mentre utilizziamo la sintassi basata su oggetto.proprietà per il ProductPrice. Questo vi lascia con ben piccole differenze, es. la possibilità di verificare la presenza di una coppia chiave/valore nel collezione di dati del ViewData (usando il metodo ContainsKey()). Alla fine di questa giornata dovreste utilizzare l'approccio che preferite di più e usare sempre quello per coerenza.

Riepilogo

Potete passare dati da un Controller ad una View usando differenti approcci, ma quello raccomandato è quasi sempre la View on un Model tipizzato dove nel Controller definite e valorizzate una istanza del tipo con cui avete definito il Model e che la View si aspetta. Questo vi darà il supporto di IntelliSense ed una verifica al momento della compilazione che le proprietà ed i metodi siano usati correttamente.