Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
add comment

4 Answers

up vote 7 down vote accepted

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:

  1. If you've gotten it wrong, e.g. 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.
  2. If you declare 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?
share|improve this answer
1  
Wouldn't 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. –  R. Martinho Fernandes Apr 16 '11 at 22:49
2  
+1 - @Martinho Frenandes "Give me static types or give me death!". Read Haackeds post on duck typing. haacked.com/archive/2007/08/19/… –  P.Brian.Mackey Apr 16 '11 at 23:41
    
Great point Martinho! I have added to the answer regarding that. –  Carson63000 Apr 17 '11 at 0:54
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.