While working with ASP.NET MVC applications you often need to pass data from controller action methods to the view. And there are various techniques to accomplish that goal - ViewData, ViewBag and TempData. This article explains these techniques, their usage and the difference between them.
In an ASP.NET MVC application a controller can easily pass a model to a view using an overloaded View() method as shown below:
public ActionResult Index()
{
List<Customer> model = GetCustomers();
return View(model);
}
As you can see the Index() method gets a List of Customer objects from a hypothetical GetCustomers() helper method and then passes it to the Index view by calling the View() method. The Index view can then access this model using the Model property.
Although passing data to a view through a model or view model class is a recommended practice, at times you need to pass some arbitrary data to the view. For example, you may need to pass a success or error message from a controller to a view so that it can be rendered in the browser. Or you may want to pass an auxiliary object holding some calculated results to the view. Since such data is not a part of the model you need some mechanism to pass it to the view. That is where ViewData, ViewBag and TempData objects come into picture. ViewData, ViewBag and TempData are inbuilt objects available to controllers and views. Each of these objects have their own specialties and features. So, let's examine each of them in bit more detail.
If you need to pass reasonable amount of data from a controller to a view that's not a part of model itself, you should give a thought to creating a view model. If something can't go in view model for some reason you can use the techniques discussed here to facilitate the data transfer.
ViewData
The primary purpose of ViewData is to carry data from the controller to the view. ViewData is a dictionary object and is of type ViewDataDictionary. Just like any other dictionary object in .NET, ViewData allows you to store key-value pairs. Data stored in ViewData object exists only during the current request. In other words, as soon as the view is rendered in the browser the ViewData object is emptied.
The following code shows an action method that sets a ViewData key named message with a developer defined message.
public ActionResult Index()
{
Customer model = new Customer() {
CustomerID = "ALFKI",
CompanyName = "Company 1",
ContactName = "Contact 1",
Country = "Country 1" };
ViewData["message"] = "This is a test message";
return View(model);
}
The Index() action method creates an instance of Customer class. The Customer object thus created is supposed to act as the model for the Index view. Then the code stores message key in the ViewData dictionary with its value set to This is a test message. Finally, the action method returns Index view by calling View() method and passing Customer model to it.
The following code from the Index view shows how ViewData dictionary can be accessed inside a view.
@model ViewDataViewBagTempData.Models.Customer
@{
Layout = null;
}
<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width" />
<title>Index</title>
</head>
<body>
<h1>@Model.CustomerID</h1>
<h3>@ViewData["message"]</h3>
<h2>@ViewData.Model.CompanyName</h2>
</body>
</html>
Notice the code marked in bold letters. The @model sets the data model for the view to ViewDataViewBagTempData.Models.Customer. This data model can be accessed using Model property as shown by @Model.CustomerID line. Next, the code outputs the value of message ViewData key using the dictionary syntax. The last line marked in bold letters may surprise you. It uses Model property of ViewData object to access the model associated with the view. So, ViewData provides a pointer to the model although you will use it rarely in this fashion because the model is directly available to a view through Model property.
As soon as the request-response cycle completes the ViewData dictionary is emptied.
In the preceding example, you stored a string value in ViewData. You could have stored any other type of data such as integer, Boolean or object. The following code stores CustomerInfo object into ViewData:
public ActionResult Index()
{
Customer model = new Customer() { ... };
CustomerInfo info = new CustomerInfo() {
LastOrderID = 100,
LastOrderDate = new DateTime(2013, 01, 20),
LastOrderAmount = 12345.6M };
ViewData["extrainfo"] = info;
return View(model);
}
The above code creates Customer model as before. Additionally, it creates an instance of CustomerInfo class. The CustomerInfo class has three properties - LastOrderID, LastOrderDate and LastOrderAmount. It then sets a ViewData key named extrainfo to this CustomerInfo object.
Whatever you store inside ViewData gets stored as a generic object and you must typecast it while retrieving it inside a view. The following code shows how:
<h3>@{
CustomerInfo info = (CustomerInfo)ViewData["extrainfo"];
@info.LastOrderID
@: |
@info.LastOrderDate
@: |
@info.LastOrderAmount
}</h3>
As you can see the above code residing in the Index view retrieves extrainfo from ViewData and typecasts it to CustomerInfo class. You can then use properties of CustomerInfo class to display their values in the view. Remember that you also need to check for null values in your view in case you expect ViewData entries to be null.
ViewBag
ViewBag is a wrapper over ViewData and allows you to store and retrieve values using object-property syntax rather than key-value syntax used by dictionary objects. It does so using the dynamic data type feature of .NET. In addition to providing object-properties syntax ViewBag also saves you from the job of typecasting as you did with ViewData object. Let's see how ViewBag can be used:
public ActionResult Index()
{
Customer model = new Customer() { ... };
CustomerInfo info = new CustomerInfo() { ... };
ViewBag.ExtraInfo = info;
return View(model);
}
As you can see, this time the code uses ViewBag object to store CustomerInfo object. It does so by declaring a developer defined property ExtraInfo and setting it to info object. If you observe ViewData object in Quick Watch window you will see this:
The ExtraInfo dynamic property is actually stored as ExtraInfo ViewData key ! Of course, you should stick to a uniform syntax while accessing this object (stick to ViewBag syntax in this case).
To retrieve CustomerInfo passed to the view you will write the following code:
<h3>@{
@ViewBag.ExtraInfo.LastOrderID
@: |
@ViewBag.ExtraInfo.LastOrderDate
@: |
@ViewBag.ExtraInfo.LastOrderAmount
}</h3>
This time you don't need to typecast ExtraInfo to CustomerInfo and you can access its properties directly (Remember, however, that these properties won't be displayed in VS IntelliSense as such).
While deciding whether to use ViewData or ViewBag you need to consider developer choice and need for typecasting. Since ViewBag is just a wrapper over ViewData, whatever you store inside ViewBag is accessible only during the current request.
TempData
TempData offers a dictionary storage like ViewData. However, values stored in TempData exists unless they are read in some view. Most commonly TempData is used to pass a value between the current request and the subsequent request. Consider an example where you are deleting a record from the database. You have created two action methods - Index() and Delete(). The Index() action method fetches a set of record and passes then to Index view to display in a table. The Index view consists of a table showing all the records and each table row has a Delete link that points to the Delete() action method. The Delete() action method does the job of deleting a record and once a record is deleted it takes the control to Index() action method so that the table can be re-displayed. Now suppose that when the table is re-displayed after deleting a record you wish to display a message to the user informing that so-and-so record has been deleted. You can't pass such a message using ViewData or ViewBag because here one request (the one that causes deletion) wants to pass data to another request (the one that renders a table of records).
The following code makes this clear:
public ActionResult Index()
{
Customer model = new Customer() { ... };
return View(model);
}
public ActionResult Delete(int id)
{
//delete record here
TempData["message"] = "Record deleted successfully!";
//transfer control to Index(). This will be another request.
return RedirectToAction("Index");
}
In this case request that invokes Delete() is the first request. During this request you store a TempData key named message and assign it some value. You then call RedirectToAction() to take the control to Index() method. Remember that RedirectToAction() returns HTTP 302 response to the browser so that the browser makes a GET request to the specified action method. At this point of time the second request is made. You wish to access data set during the first request in the second request and hence you use TempData.
The value set in the TempData can be accessed in the Index view like this:
<body>
<h1>Index View</h1>
<h3>@TempData["message"]</h3>
</body>
So far so good. While the above example works as expected, you need to be aware of a tricky thing. If you don't read the TempData values in the second request, they are persisted and can be read in yet subsequent request. They exist unless you read them in some view at which point of time they are removed. Consider the following code that makes this behavior clear:
public ActionResult Index1()
{
TempData["message"] = "Test message!";
return View();
}
public ActionResult Index2()
{
return View();
}
public ActionResult Index3()
{
return View();
}
Assume that Index1 view has a link pointing to Index2 action method and Index2 view has a link pointing to Index3 action method. Now, if Index1 and Index2 views do not use TempData at all then it is still available to Index3 view. However, if Index1 or Index2 views use TempData then it is removed as soon as the respective request completes. Index3 view won't be able to read TempData value in that case.
There is one more twist in the TempData story that you should be aware of. The TempData object has Keep() method that can preserve the value(s) even after they are read. To do so, once you finish reading the values call TempData.Keep() or TempData.Keep(<key>). Calling Keep() marks the tempdata key(s) for retention till next read operation.
It would be interesting to know that TempData values are actually stored in ASP.NET Session and are automatically removed once they are read. To prove that they are indeed stored in Session just disable session state altogether by adding this line in web.config:
<sessionState mode="Off"></sessionState>
If you try to run the same example now, you will get this error.
Just like ViewData, TempData also requires typecasting and null value checking while accessing its values.
To summarize,
- ViewData, ViewBag and TempData allow you to pass values from a controller to a view.
- ViewData and TempData objects allow you to store values as key-value pairs.
- ViewBag object allows you to store values using object-properties syntax.
- ViewBag is a wrapper over ViewData.
- ViewData and ViewBag values are available only during current request.
- TempData values are accessible in the current request and the subsequent requests. They are removed when a view reads them.
- TempData internally uses Session to store its values. The values are removed once they are read.
- ViewData and TempData require typecasting and null checking whereas ViewBag doesn't need such checking.
