When passing information from an action method to a view, you basically have three options:
• Use the ViewData dictionary.
• Use ViewBag (starting in MVC 3).
• Use a strongly typed view with a view model object
ViewData and ViewBag allow you to add information (primitive types such as integers or even complex objects) that will later be accessible to the view for generating HTML. Using strongly typed views is discussed in the next section.
ViewData is simply a dictionary that uses the key/value pattern. An example of how to use ViewData is provided in Listing 1. Note that the information in the ViewData dictionary is simply added by giving it a name and setting its value.
Listing 1. Using ViewData to Pass Information from the Action Method to the View
// Action Method
public ActionResult ShowError()
{
ViewData["ErrorCode"] = 12345;
ViewData["ErrorDescription"] = "Something bad happened";
ViewData["ErrorDate"] = DateTime.Now;
ViewData["Exception"] = new Exception();
return View();
}
@* View *@
<h1>An error was found</h1>
<h2>Error Code: @ViewData["ErrorCode"]</h2>
<h2>Error Date: @ViewData["ErrorDate"]</h2>
<h2>@ViewData["ErrorDescription"]</h2>
ViewBag is different from ViewData in the sense that it implements the dynamic features introduced in C# 4. Basically, the difference is that properties can be added to ViewBag dynamically. Listing 2 shows the code in Listing 1 modified to use ViewBag.
Listing 2. Using ViewBag to Pass Information from the Action Method to the View
//Action Method
public ActionResult ShowError()
{
ViewBag.ErrorCode = 12345;
ViewBag.ErrorDescription = "Something bad happened";
ViewBag.Exception = new Exception();
return View();
}
@* View *@
<h1>An error was found</h1>
<h2>Error Code: @ViewBag.ErrorCode</h2>
<h2>@ViewBag.ErrorDescription</h2>
After viewing the code in Listings 1 and 2, you will notice that they are very similar—and there is a good reason for that. ViewBag is simply a dynamic implementation of ViewData. Under the hood, ViewBag uses ViewData as a storage mechanism, so either way you end up using a dictionary; the difference is the syntax used to set and get the information.
You might be thinking now, “If they are using the same dictionary, I can use them interchangeably.” Well, yes and no. Technically, there is no reason not to do so (nor any associated problems); for example, you can use ViewBag.ErrorCode = 12345; in the action method and then use <h2>@ViewData["ErrorCode"]</h2> in the view. However, I recommend using ViewBag simply because it is a bit easier than ViewData due to its dynamic nature.
One last thing to consider when using ViewData and ViewBag is that the information in the dictionary is lost after the view is rendered. This is important because you could, for example, use RedirectToAction in your action method to call a different action method. If a RedirectToAction happens after you add values to ViewData (or ViewBag), it will cause the browser to issue a 302 HTTP redirect (a temporary redirect). At this point, a completely new request is sent to the server and the new action method won’t have access to the information previously added to ViewData. In this scenario, you will have to use a different object that is designed to have a short life but is capable of surviving redirects. The object is TempData, which, as opposed to ViewData, is stored in the current session instead of a dictionary. Use TempData with caution, as the information is promptly discarded once the redirect is complete. If you refresh the page, the information in TempData won’t be available.
• Use the ViewData dictionary.
• Use ViewBag (starting in MVC 3).
• Use a strongly typed view with a view model object
ViewData and ViewBag allow you to add information (primitive types such as integers or even complex objects) that will later be accessible to the view for generating HTML. Using strongly typed views is discussed in the next section.
ViewData is simply a dictionary that uses the key/value pattern. An example of how to use ViewData is provided in Listing 1. Note that the information in the ViewData dictionary is simply added by giving it a name and setting its value.
Listing 1. Using ViewData to Pass Information from the Action Method to the View
// Action Method
public ActionResult ShowError()
{
ViewData["ErrorCode"] = 12345;
ViewData["ErrorDescription"] = "Something bad happened";
ViewData["ErrorDate"] = DateTime.Now;
ViewData["Exception"] = new Exception();
return View();
}
@* View *@
<h1>An error was found</h1>
<h2>Error Code: @ViewData["ErrorCode"]</h2>
<h2>Error Date: @ViewData["ErrorDate"]</h2>
<h2>@ViewData["ErrorDescription"]</h2>
ViewBag is different from ViewData in the sense that it implements the dynamic features introduced in C# 4. Basically, the difference is that properties can be added to ViewBag dynamically. Listing 2 shows the code in Listing 1 modified to use ViewBag.
Listing 2. Using ViewBag to Pass Information from the Action Method to the View
//Action Method
public ActionResult ShowError()
{
ViewBag.ErrorCode = 12345;
ViewBag.ErrorDescription = "Something bad happened";
ViewBag.Exception = new Exception();
return View();
}
@* View *@
<h1>An error was found</h1>
<h2>Error Code: @ViewBag.ErrorCode</h2>
<h2>@ViewBag.ErrorDescription</h2>
After viewing the code in Listings 1 and 2, you will notice that they are very similar—and there is a good reason for that. ViewBag is simply a dynamic implementation of ViewData. Under the hood, ViewBag uses ViewData as a storage mechanism, so either way you end up using a dictionary; the difference is the syntax used to set and get the information.
You might be thinking now, “If they are using the same dictionary, I can use them interchangeably.” Well, yes and no. Technically, there is no reason not to do so (nor any associated problems); for example, you can use ViewBag.ErrorCode = 12345; in the action method and then use <h2>@ViewData["ErrorCode"]</h2> in the view. However, I recommend using ViewBag simply because it is a bit easier than ViewData due to its dynamic nature.
One last thing to consider when using ViewData and ViewBag is that the information in the dictionary is lost after the view is rendered. This is important because you could, for example, use RedirectToAction in your action method to call a different action method. If a RedirectToAction happens after you add values to ViewData (or ViewBag), it will cause the browser to issue a 302 HTTP redirect (a temporary redirect). At this point, a completely new request is sent to the server and the new action method won’t have access to the information previously added to ViewData. In this scenario, you will have to use a different object that is designed to have a short life but is capable of surviving redirects. The object is TempData, which, as opposed to ViewData, is stored in the current session instead of a dictionary. Use TempData with caution, as the information is promptly discarded once the redirect is complete. If you refresh the page, the information in TempData won’t be available.
No comments:
Post a Comment