Using TempData in ASP.NET MVC

TempData in ASP.NET MVC is basically a dictionary object derived from TempDataDictionary. TempData stays for a subsequent HTTP Request as opposed to other options (ViewBag and ViewData) those stay only for current request. So, TempdData can be used to maintain data between controller actions as well as redirects.

Note: Just like ViewData, typecasting and null checks required for TempData also in order to avoid errors.

Let’s see how we can use TempData in a practical scenario to pass data from one controller action to another.

   //Controller Action 1 (TemporaryEmployee)

   public ActionResult TemporaryEmployee()
  {
                  Employee employee = new Employee
                  {
                          EmpID = “121″,
                          EmpFirstName = “Imran”,
                          EmpLastName = “Ghani”
                  };                   

                  TempData[“Employee”] = employee;
                  return RedirectToAction(“PermanentEmployee”);
  }   

   //Controller Action 2(PermanentEmployee)

   public ActionResult PermanentEmployee()
  {
                 Employee employee = TempData[“Employee”] as Employee;
                 return View(employee);
   }

As in above example, we store an employee object in TempData in Controller Action 1 (i.e. TemporaryEmployee) and retrieve it in another Controller Action 2 (i.e. PermanentEmployee). But If we try to do the same using ViewBag or ViewData, we will get null in Controller Action 2 because only TempData object maintains data between controller actions.

An important thing about TempData is that it stores contents in Session object. Then one may raise a question that  “What’s the difference between TempData in ASP.NET MVC and Session?” or “Why we have TempData dictionary object?, Why can’t we use the Session object directly?”

ASP.NET MVC TempData Vs Sessions

Although ASP.NET MVC TempData stores it’s content in Session state but it gets destroyed earlier than a session object. TempData gets destroyed immediately after it’s used in subsequent HTTP request, so no explicit action required. If we use a Session object for this purpose, we would have to destroy the object explicitly.

It’s best fit for scenarios when:

• we need to preserve data from current to subsequent request.
• passing error message to an error page.