Differenze tra IActionResult, ViewData, ViewBag e TempData in asp.net core mvc

Solitamente in asp.net core mvc nell’ActionResult si ritorna la risposta del controller, mentre si utilizzano ViewBag, ViewData e TempData per passare ulteriori informazioni alla view.

Introduzione

ASP.NET MVC Core è la nuova versione del framework di Microsoft per costruire applicazioni usando il design pattern Model-View-Controller. Lo scopo di questo pattern è separare un’applicazione in tre macro aree principali : Model, View e Controller. In questo modo otteniamo un architettura chiara e pulita (“separation of concerns”). Utilizzando questa architettura le richieste degli utenti vengono instradate a un Controller (in base alle regole di routing presenti), il quale è responsabile di lavorare con il Modello per eseguire azioni dell’utente e / o recuperare i risultati delle query. Il controller sceglie poi la vista con cui mostrare all’utente i dati richiesti.

Sia il controller che la view dipendono dal modello. Tuttavia il modello non dipende né dalla vista né dal controller. Questo è uno dei principali vantaggi della separazione delle responsabilità.

Questo implica la necessità di dover passare dati tra un area e l’altra, il controller dopo aver recuperato i dati deve passarli alla view. Come possiamo fare? Per fa questo abbiamo a disposizione 4 opzioni.

IActionResult

L’opzione principale (e anche quella di default) è creare una view tipizzata alla quale il controller passa un oggetto. All’interno del controller recuperiamo i dati che vengono poi passati alla view attraverso il metodo “view(‘nome-view’, <oggetto>)”.

All’interno della view come prima istruzione compare la dichiarazione del tipo di oggetto passato, a questo punto possiamo poi referenziarlo attraverso l’oggetto build-in “Model”.

Seguendo questa strada i vari HtmlHelper presenti nella view riescono a vedere l’oggetto passato, pertanto sono in grado di generare il codice html sottostante con i corretti valori impostati.

Fin qui nulla di strano, ma come facciamo se dobbiamo passare alla view più di un oggetto? Per esempio oltre all’oggetto “customer” anche la lista delle “city”. Le view tipizzate possono mappare solo un oggetto!

In questo frangente ci vengono in aiuto gli oggetti “ViewData” e “ViewBag” presenti sia nel controller che nella view.

ViewData

ViewData è un dictionary derivato dalla classe “ViewDataDictionary”; essendo un dictionary non fornisce nessun controllo per ciò che riguarda i nomi dei key/value inseriti, per questo motivo se inseriamo un nome errato nel momento in cui proviamo a recuperarlo otterremo un errore a runtime.

L’oggetto ViewData si occupa solo di trasferire i dati dal controller alla view (e non il viceversa), inoltre non mantiene ciò che è stato inserito tra una richiesta e l’altra come avviene nel caso dell’oggetto cache o sessione.

ViewBag

ViewBag è invece una proprietà dinamica presente sia nel controller che nella view (come nel caso dell’oggetto ViewData). Tecnicamente parlando l’oggetto ViewBag è una wrapper attorno all’oggetto ViewData.

Anche in questo caso l’oggetto ViewBag si occupa solo di trasferire i dati dal controller alla view (e non il viceversa), inoltre non mantiene ciò che è stato inserito tra una richiesta e l’altra come avviene nel caso dell’oggetto cache o sessione.

Nell’esempio sovrastante abbiamo inserito nell’oggetto ViewData la lista delle città, all’interno della view abbiamo poi recuperato la lista delle città per poi passarla alla DropDowListFor(). Per quanto riguarda l’oggetto ViewBag, abbiamo creato una proprietà “title” alla quale abbiamo assegnato un valore, all’interno della view abbiamo poi recuperato il valore per visualizzarlo all’interno di un tag h2.

TempData

Esiste poi un oggetto speciale: “TempData”. A differenza di “ViewData” e “ViewBag” che possono solo passare valori solo tra controller e la view (e non il viceversa), come non mantengono il valore tra una richiesta e l’altra.

L’oggetto “TempData” viene utilizzato per trasferire valori dal controller alla view, dalla view al controller o tra un action a un’altra action. L’oggetto “TempData” memorizza i valori temporaneamente e li rimuove automaticamente dopo che il valore è stato recuperato.

Conclusioni

Al fine di avere un architettura chiara e pulita si consiglia che il controller sia slim. Ovvero il codice contenuto in esso deve solo essere quello necessario a coordinare un processo contenuto in altri oggetti. Per far questo ci viene in aiuto il meccanismo di “dependency-injection” presente in ASP.NET MVC Core, in questo modo possiamo farci iniettare degli oggetti di “Business” che si occupano in dettaglio di ciò che vogliamo fare.

Se volete contattarmi il mio profilo Linkedin è il seguente: Stefano Marchisio: Consulente freelance Angular ASP.NET MVC C#