Why everybody hates ViewData?

Question

I wonder, why everybody hates ViewData so much?
I find it quite useful and convenient. I tell you why: typically every controller action has it's own ViewModel, so it's used only once and I find it very tedious to modify ViewData class every time I need to add extra portion of data to view (adding extra field to class usually leads to modifying its constructor). Instead I can write in controller

ViewData["label"] = someValue;
// in mvc 3 even better:
ViewData.Label = someValue

and in view

<%= ViewData["label"] %>
<%-- mvc 3: --%>
<%= ViewData.Label %>

or for complex types:

<% ComplexType t = (ComplexType)ViewData["label"]; %> // and use all benefits of strong typing 
<%= t.SomeProperty %>

Writing a controller action I do not have to switch to another class, when I need to add some data to view. And a big plus for me: no flooding your project with senseless classes and switching between them and others.
I agree that usage of "magic strings" could lead errors which are not caught by compiler, but these errors localized in very small part of code and can be discovered very quickly. Besides, how do you think guys working with dynamic languages (rails, django) lives without strong typing at all?)

What's your opinion about using ViewData?

Answer 1

Weeellll.....

Why don't you write classes this way?

public dictionary<string, object> myCollectionOfClasses;
myCollectionOfClasses.Add("MyClass", new MyClass);

public class MyClass
{
    public string DoSomething
    {
        return "SomeString";
    }
}

You would have to call them this way:

string myString =  myCollectionOfClasses["MyClass"].DoSomething();

Now which is sillier?

See also
How we do MVC – View models

Answer 2

First of all, awesome +1 for letting me know about how MVC3 does viewdata! I've been wanting to find some way of doing something like that in MVC2.
As for why viewdata is bad? I don't feel it is as long as it is used sparsely AND is tested for in expectations. There are two major pain points for using viewdata:

1) Failing to include viewdata causes exceptions on a view which are not caught by the compiler. I have helped myself out with this issue by not using the much vaulted T4MVC template (altho I do recommend it) and instead "write" something similar myself:

        /// <summary>
        /// Main Greeting
        /// ViewData: ViewDataConstants.Message
        /// </summary>
        public const string Index = "~/Views/Home/Index.aspx";

Using this, my intellisense will give me a heads up when I return this.View(ViewConstants.Home.Index); If I knew enough T4 to alter T4MVC to do this for me, I'd switch back to having this generated ;)

2) Typos are a pain. That's why, as you will see above, I use a static class not only for view names, but also for viewdata indexers. When I do use viewdata, you'll see code like this in my pages:

<%: ViewData[ViewDataConstants.Message] %>

If you can keep those two pain points in check, and keep usage to an acceptable low level, viewdata has it's benefits and should not be overlooked.

Answer 3

I think this goes beyond just the magic string argument. I would argue that ViewModels are a good thing and not senseless classes because they help keep the Views cleaner and easier to read than accessing ViewData all over the Views.

When you get to five, ten, twenty pieces of data that need to be displayed in a view are you really going to pass all that data over as ViewData? It will make your view harder to follow and that data won't have any meaning. Making a ViewModel and strongly typing the view to that ViewModel will not only make the code easier to read, but you don't have to go casting ViewData objects all over your code.

I do think ViewData is good for certain cases, but when you are dealing with a lot of data it can easily be abused in my opinion.