Qual'è la logica dietro l'idea di rendere ViewBag un oggetto dinamico in ASP.NET MVC 3

È lo zucchero sintattico, in pratica. Non penso che sia inteso per essere funzionalmente "migliore" del vecchio dizionario ViewData , solo molto meno verboso con cui lavorare. Invece di estrarre le cose dal dizionario e lanciarle manualmente (e bloccarsi se sono sbagliate), puoi semplicemente usarle senza alcuna verbosità extra (e bloccarti se sono sbagliate).

Qui è un post del blog che contiene alcuni esempi di codice "prima e dopo" che utilizzano il vecchio dizionario ViewData e il nuovo ViewBag dinamico. In particolare, guarda foreach iterando attraverso l'elenco di stringhe.

foreach (var color in ViewData["listColors"] as List<string>)

.. diventa ..

foreach (var color in ViewBag.ListColors)

Modifica: Martinho è un punto eccellente! La nuova versione dovrebbe probabilmente dichiarare esplicitamente un string piuttosto che un var , in questo modo:

foreach (string color in ViewBag.ListColors)

Due motivi:

1. Se hai sbagliato, ad es. ViewBag.ListColors è un List di System.Drawing.Color oggetti, riceverai un errore immediato e chiaro, Cannot convert type 'System.Drawing.Color' to 'string' , piuttosto che un output strano e indesiderato.
2. Se dichiari color come var , l'inferenza di tipo lo dedurrà come dynamic , quindi tutto il suo utilizzo nel ciclo passerà attraverso l'associazione tardiva del Dynamic Language Runtime, giusto? Sicuramente questo è un colpo di performance non necessario?

In alternativa al dizionario ViewData, non c'è molto da perdere rendendo ViewBag dinamico - stavate già affrontando un pasticcio di cose non tipizzato in ogni caso - non vi è alcun reale svantaggio nel rimuovere alcuni dei cruft intorno all'accesso alle proprietà di ViewData.

Se il controllo del tipo (e l'IMO di interazione vista / controllore più pulito) è auspicabile, non ti viene impedito di utilizzare le visualizzazioni con caratteri forti.

C'è un vantaggio operativo - dovrebbe aiutare a impedirne l'esecuzione da parte di eccezioni di riferimento null bizzarre.

Diciamo che sto cercando una birra nel mio viewbag, ma ho dimenticato di inserirla.

var beer = ViewBag["Beer"] as Beer;

Mi dà riferimento null. Quindi, quando chiamo beer.Drink() ottengo un'eccezione di riferimento null che ho bisogno di tornare indietro alla catena per capire.

Se scrivi il codice come

var beer = ViewBag.Beer;

E ti sei dimenticato di aggiungere la birra, si verificherà un errore su quella linea e la causa sarà un po 'più ovvia.

Risposta breve: per rendere più simile a Ruby e riconquistare le persone che hanno abbandonato MVC per Rails.

Risposta lunga (er): sono abbastanza sicuro che abbia a che fare con la flessibilità di MVC e il fatto che il framework MVC già ti fa usare C # in un modo leggermente più dinamico del vecchio modello WebForms.