Should ViewData never be used?

Question

I have tried to check the best practices for using asp.net mvc and quite a few say that we should never use ViewData. I have read this post and it seems like it from that.

One reason that I can think of using ViewData is if you are looking to pass just one value to the view.But for more than one values it seems that it would better to use ViewModels. But if they are being included as a part of framework then they should have some advantages and benefits.

What are the cases when I should use ViewData ? What are the best practices to be followed when using ViewData so that it is not misused ?

score 3 · Accepted Answer · edited Jun 21 '19 at 07:59

3

I prefer to use strongly typed view models from the outset. I much prefer the lack of "magic strings" by doing this.

Never one rule for all situations but this is usually the first approach I take.

edited Jun 21 '19 at 07:59

halfer

19,824
17
99
186

answered Jan 14 '11 at 22:27

Daniel Elliott

22,647
10
64
82

magic strings themselves can be avoided by having constant strings.. just saying.. – Baz1nga Jun 19 '12 at 10:00

score 0 · Answer 2 · answered Jan 14 '11 at 22:38

Quote from Scot Gu (link to source: nerddinnerbook)

Using string-based dictionaries, since typos, can lead to errors that will not be caught at compile-time. The un-typed ViewData dictionary also requires using the "as" operator or casting when using a strongly-typed language like C# in a view template.

score 0 · Answer 3 · edited Jan 14 '11 at 22:43

0

Usage of a strongly typed ViewPages in couple with a strongly typed Model or ModelView is a perfect practice of the ASP.NET MVC.

You can use ViewData to transfer additional data to ViewPage but I preffer ViewModels because:

Compile time errors vs runtime errors
IntellySence support
Easy refactoring
No magic strings
Html helper to construct form with data bindings

edited Jan 14 '11 at 22:43

Nathan Taylor

24,423
19
99
156

answered Jan 14 '11 at 22:41

Viacheslav Smityukh

5,652
4
24
42

Nathan Taylor · Answer 4 · 2011-01-14T22:52:16.220

I often find myself using ViewData when I need to append data to the current request by way of some base controller or filter. Commonly, master pages will have dynamic content which must be retrieved from the server, and rather than modifying the model returned by the view, or wrapping every model returned in a parent ViewModel, I can simply place the additional data in ViewData.

In order to avoid using strings in my views, I'll often place a const field in a controller class or similar and call the field within the View.

public abstract partial class BaseController : Controller
{
    public const string MessagesViewDataKey = "Base.Messages";

    protected override void OnActionExecuted(ActionExecutedContext filterContext) {
        if (filterContext != null && filterContext.Controller != null && !filterContext.IsChildAction) {
            filterContext.Controller.ViewData[MessagesViewDataKey] = Messenger.MessageQueues;
        }

        base.OnActionExecuted(filterContext);
    }
}

// site.master
<% if (ViewData[BaseController.MessagesViewDataKey] != null)
           Html.RenderPartial("DisplayTemplates/MessageList", ViewData[BaseController.MessagesViewDataKey]); %>

score 0 · Answer 5 · answered Jan 14 '11 at 22:51

I don't like using them, but I've found them useful in a situation where I want to display some kind of message to the user on all pages. For example I have a user control that displays messages to the user. It is also present in my master page. It checks ViewData["messages"] and TempData["messages"] And if one of those is not null it displays the messages that are present. If they are both null it doesn't.

This allows me to keep all of my models from having to inherit from a base class that has a Messages property and gives me more flexibility.

Should ViewData never be used?

5 Answers5