Last time I checked C# was loved by many because it's a statically typed language but the introduction of ViewBag in ASP.NET MVC 3 brings the same problem that is there with strings: in a controller you type one thing and in the view you can by mistake type something else.
What's the reason for making ViewBag dynamic? How is it better?
It's syntactic sugar, basically. I don't think it's meant to be functionally "better" than the old ViewData dictionary, just a lot less verbose to work with. Instead of taking things out of the dictionary and manually casting them (and crashing if they're wrong), you can just use them without any extra verbiage (and crash if they're wrong).
Here is a blog post which has some "before and after" code samples using the old ViewData dictionary and the new ViewBag dynamic. In particular, see the foreach iterating through the list of strings.
foreach (var color in ViewData["listColors"] as List<string>) ..becomes..
foreach (var color in ViewBag.ListColors) Edit: Martinho makes an excellent point! The new version should probably explicitly declare a string rather than a var, like so:
foreach (string color in ViewBag.ListColors) Two reasons:
ViewBag.ListColors is a List of System.Drawing.Color objects, you'll get an immediate and clear error, Cannot convert type 'System.Drawing.Color' to 'string', rather than weird and undesired output.color as a var, the type inference will infer it as a dynamic, thus all the usage of it in the loop will go through the Dynamic Language Runtime's late binding, right? Surely this is an unnecessary performance hit?
foreach(string color in ViewBag.ListColors) be better? You know, to get back to the static typed world as soon as possible. And fail fast if you messed up. As an alternative to the ViewData dictionary, there's not much lost by making ViewBag dynamic - you were already dealing with an untyped mess of things anyway - there's no real disadvantage to removing some of the cruft around accessing properties of ViewData.
If type checking (and cleaner View / Controller interaction IMO) is desirable to you, you're not prevented from using strongly-typed views.
There is one operational advantage -- should help keep one from running down weird null reference exceptions.
Let's say I'm looking for a beer in my viewbag, but I forgot to put it in.
var beer = ViewBag["Beer"] as Beer; Gives me null reference. So, when I call beer.Drink() I get a null reference exception which I need to backtrack up the chain to figure out.
If you write the code as
var beer = ViewBag.Beer; And you forgot to add the beer, it will error out on that line and the cause will be a bit more obvious.
Short answer: To make it more Ruby-like and win back the people who abandoned MVC for Rails.
Long(er) answer: I'm fairly sure it has to do with the flexibility of MVC and the fact that the MVC framework already makes you use C# in a slightly more dynamic way than the old WebForms model.
