asp.net mvc ViewData 和 ViewBag区别，TempData

浏览数：60 / 时间：2015年06月09日

ViewData 和 ViewBag都是页面级别的生命周期，TempData--Passing data between the current and next HTTP requests

TempData默认是实现方式--存在session中，所以结论很简单，能不用就不用。。要么负载时就麻烦了。

Passing data between the current and next HTTP requests - See more at: http://www.rachelappel.com/when-to-use-viewbag-viewdata-or-tempdata-in-asp.net-mvc-3-applications#sthash.rVx9t9N8.dpuf

先上源码：

ControllerBase中如下定义2个：

private DynamicViewDataDictionary _dynamicViewDataDictionary;
private TempDataDictionary _tempDataDictionary;

        public dynamic ViewBag {
            get {
                if (_dynamicViewDataDictionary == null) {
                    _dynamicViewDataDictionary = new DynamicViewDataDictionary(() => ViewData);
                }
                return _dynamicViewDataDictionary;
            }
        }

        [SuppressMessage("Microsoft.Usage", "CA2227:CollectionPropertiesShouldBeReadOnly", 
Justification = "This property is settable so that unit tests can provide mock implementations.")]
        public ViewDataDictionary ViewData {
            get {
                if (_viewDataDictionary == null) {
                    _viewDataDictionary = new ViewDataDictionary();
                }
                return _viewDataDictionary;
            }
            set {
                _viewDataDictionary = value;
            }
        }

可以看出ViewBag 使用ViewData(ViewDataDictionary)来保存数据，以便在view中获取相应的值。

ViewDataDictionary是实现字典接口--IDictionary<string, object>。

ViewBag--类型是net4.0才有的dynamic，该类型表示运行才知道具体的类型，编译时是无法验证类型的正确性。

好处是获取值时不需要验证值是否为null。

以下是mvc官网的解释：

MVC 2 controllers support a ViewData property that enables you to pass data to a view template using a late-bound dictionary API. In MVC 3, you can also use somewhat simpler syntax with the ViewBag property to accomplish the same purpose. For example, instead of writing ViewData["Message"]="text", you can write ViewBag.Message="text". You do not need to define any strongly-typed classes to use the ViewBag property. Because it is a dynamic property, you can instead just get or set properties and it will resolve them dynamically at run time. Internally, ViewBag properties are stored as name/value pairs in the ViewData dictionary. (Note: in most pre-release versions of MVC 3, the ViewBag property was named the ViewModel property.)

ViewData requires typecasting for complex data type and check for null values to avoid error.

ViewBag doesn’t require typecasting for complex data type.

    public ActionResult Index()

    {
    ViewBag.Name = "Arun Prakash";
    return View();
    }

    public ActionResult Index()
    {
    ViewData["Name"] = "Arun Prakash";
    return View();
    }

    //Calling in View
    @ViewBag.Name
    @ViewData["Name"]

区别是复杂类型是否需要验证null，ViewData需要，ViewBag不需要。

再来个demo：

public class HomeController : Controller
{
    public ActionResult Index()
    {
        var emp = new Employee
    {

  EmpID=101,
  Name = "Deepak",
  Salary = 35000,
  Address = "Delhi"

    };

 ViewData["emp"] = emp;
 ViewBag.Employee = emp;

return View(); 
    }
}

code for View is as follows

@model MyProject.Models.EmpModel;
@{ 
 Layout = "~/Views/Shared/_Layout.cshtml"; 
 ViewBag.Title = "Welcome to Home Page";
 var viewDataEmployee = ViewData["emp"] as Employee; //need typcasting
}
<h2>Welcome to Home Page</h2>

 This Year Best Employee is!
 <h4>@ViewBag.emp.Name</h4>
 <h3>@viewDataEmployee.Name</h3>
</div>

While the TempData object works well in one basic scenario:

Passing data between the current and next HTTP requests

If you need to work with larger amounts of data, reporting data, create dashboards, or work with multiple disparate sources of data, you can use the more heavy duty ViewModel object. See my detailed blog post on ViewModels for more details on working with ViewModels.

- See more at: http://www.rachelappel.com/when-to-use-viewbag-viewdata-or-tempdata-in-asp.net-mvc-3-applications#sthash.rVx9t9N8.dpuf

While the TempData object works well in one basic scenario:

Passing data between the current and next HTTP requests

- See more at: http://www.rachelappel.com/when-to-use-viewbag-viewdata-or-tempdata-in-asp.net-mvc-3-applications#sthash.rVx9t9N8.dpuf

Passing data between the current and next HTTP requests - See more at: http://www.rachelappel.com/when-to-use-viewbag-viewdata-or-tempdata-in-asp.net-mvc-3-applications#sthash.rVx9t9N8.dpuf

TempData is meant to be a very short-lived instance, and you should only use it during the current and the subsequent requests only!
Since TempData works this way, you need to know for sure what the next request will be, and redirecting to another view is the
only time you can guarantee this. Therefore, the only scenario where using TempData will reliably work is when you are redirecting.
This is because a redirect kills the current request (and sends HTTP status code 302 Object Moved to the client),
then creates a new request on the server to serve the redirected view.
Looking back at the previous HomeController code sample means that the TempData object could yield results differently than expected
because the next request origin can‘t be guaranteed. For example, the next request can originate from a completely different machine
and browser instance.

However, once the controller redirects, the ViewBag and ViewData will contain null values. If you inspect the TempData object with debugging
tools after the redirect you‘ll see that it is fully populated with a featured product. This is because the redirect is that only, subsequent,
request, so only it can access the TempData object without worry.

Where Is TempData Stored?

This is the part that came back to bite me. By default, TempData is stored in the session. Yes, the session! Most of the time this probably doesn’t matter to you, since as long as you get your objects back when you want them you have no reason to worry about where it was kept. However, let’s say you decide you want to switch away from the default Session-State Mode, and use State Server Mode or SQL Server Mode. These modes require that all objects stored in session be serializable. This is exactly what I did, and without knowing that TempData used the session, it was non-obvious why I started seeing session errors.

You might have noticed that I said that TempData is kept in the session by DEFAULT, meaning you are not tied to that if you decide you don’t like it that way. Let’s take a look at some of the source code to ASP.NET MVC 2 and see how things work.

ITempDataProvider and SessionStateTempDataProvider
In the System.Web.Mvc namespace you’ll find a very simple interface called ITempDataProvider that looks like this:

public interface ITempDataProvider {  
    IDictionary<string, object> LoadTempData(ControllerContext controllerContext);
    void SaveTempData(ControllerContext controllerContext,
                                IDictionary<string, object> values);
}

Not much to see there. It simply defines the methods of saving and loading the dictionary. In the same namespace is SessionStateTempDataProvider which implements ITempDataProvider. When loading the dictionary out of the session, it explicitly removes it afterwards to make sure only one request gets access to it:

public class SessionStateTempDataProvider : ITempDataProvider {
        internal const string TempDataSessionStateKey = "__ControllerTempData";

        public virtual IDictionary<string, object> LoadTempData(ControllerContext controllerContext) {
            HttpSessionStateBase session = controllerContext.HttpContext.Session;

            if (session != null) {
                Dictionary<string, object> tempDataDictionary = session[TempDataSessionStateKey] as Dictionary<string, object>;

                if (tempDataDictionary != null) {
                    // If we got it from Session, remove it so that no other request gets it
                    session.Remove(TempDataSessionStateKey);
                    return tempDataDictionary;
                }
            }

            return new Dictionary<string, object>(StringComparer.OrdinalIgnoreCase);
        }

        public virtual void SaveTempData(ControllerContext controllerContext, IDictionary<string, object> values) {
            if (controllerContext == null) {
                throw new ArgumentNullException("controllerContext");
            }

            HttpSessionStateBase session = controllerContext.HttpContext.Session;
            bool isDirty = (values != null && values.Count > 0);

            if (session == null) {
                if (isDirty) {
                    throw new InvalidOperationException(MvcResources.SessionStateTempDataProvider_SessionStateDisabled);
                }
            }
            else {
                if (isDirty) {
                    session[TempDataSessionStateKey] = values;
                }
                else {
                    // Since the default implementation of Remove() (from SessionStateItemCollection) dirties the
                    // collection, we shouldn‘t call it unless we really do need to remove the existing key.
                    if (session[TempDataSessionStateKey] != null) {
                        session.Remove(TempDataSessionStateKey);
                    }
                }
            }
        }

    }

The controller object has a public property for the TempData provider which that uses the session provider by default:

public ITempDataProvider TempDataProvider {  
    get {
        if (_tempDataProvider == null) {
            _tempDataProvider = CreateTempDataProvider();
        }
        return _tempDataProvider;
    }
    set {
        _tempDataProvider = value;
    }
}

protected virtual ITempDataProvider CreateTempDataProvider() {  
    return new SessionStateTempDataProvider();
}