ASP.NET MVC - TempData - A Closer Look

DefaultController.cs

using System.Web.Mvc;

namespace SessionHandlingInMVC.Controllers
{
    public class DefaultController : Controller
    {
        // GET: Default
        public ActionResult Index()
        {
            TempData["MyTempDataValue"] = "Value initialized in Index Action Method";
            return View();
        }
        
        public ActionResult Page1()
        {
            return View("Page1");
        }
        
        public ActionResult Page2()
        {
            return View("Page2");
        }
    }
}

<h2>Index Page</h2>
<p>
    @{
        string strTempDataValue = (string)TempData["MyTempDataValue"];
    }
    @strTempDataValue
</p>

<h2>Index Page</h2>
<p>
    @{
        string strTempDataValue = (string)TempData["MyTempDataValue"];
    }
    @strTempDataValue

    @{
        string strAnotherRead = (string)TempData["MyTempDataValue"];
    }
    @strAnotherRead
</p>

<h2>Page1</h2>
<p>
    @{
        string strTempDataValueInPage1 = (string)TempData["MyTempDataValue"];
    }
    @strTempDataValueInPage1
</p>

In order to test the above scenario, first you must render the view “Index” (since in that action method alone the tempdata value is initialized) and then you call the “Page1” view. As you can see, TempData value is not available in the next request.

Wait! The conclusion is not yet over. I want to try something more. That is, as per the above codes.

1. First I render the “Index” page, where the Tempdata value is read and print it.
2. After I call the action method “Page1”.

What will happen if I don’t read the value of Tempdata in the “Index.cshtml” view and try to read the “Page1.cshtml” view? In order to test, I made the below changes in the Index view.

Index.cshtml

<h2>Index Page</h2>
<p>
    No Temp Data read here in Index.cshtml
</p>

Page 1. .cshtml

<h2>Page1</h2>
<p>
    @{
        string strTempDataValueInPage1 = (string)TempData["MyTempDataValue"];
    }
    @strTempDataValueInPage1
</p>

Now, you get the value in the value of Tempdata in the next request. That means, your first request renders the “Index” page, and the next request renders “Page1”.

If you refresh the above page, you will get the result below: that is, the Tempdata is unavailable once it is read. So you get the Tempdata value as empty.

So the conclusion is that after Tempdata value is initialized and it’s not yet read in the current request, then it will be available in the next request. Once it is read, it will not be available.

A few words about Keep() and Peek() method

After you read the tempdata, if you call the keep method, it will mark all tempdata keys or specific keys for retention. If you want to fetch the key and mark the key for retention (keep the key for the next request) then you can go with the Peek method.

Connection between Session and Tempdata

Yes, Tempdata uses a “Session” object in the backend. That is, whenever you use a tempdate it will be handled by session. But the main difference is, the Tempdata will be removed (by default) after the first read.

At the same time, you may have a doubt, is tempdata specific to the user as like as “Session”? The answer is Yes. Since the Tempdata, is backed up with Session, Tempdata is also specific to the user, like the Session object.

Also, the other question is, since the Tempdata is backed up with Session, what will happen if we go with the same key for Session and Tempdata as below?

The answer is it won’t colloid. It will considered as a different one and it will serve its own purpose as per the convention.

Summary

1. TempData stores the value using the key.
2. TempData is backed up with Session.
3. Need type casting when the stored value is retrieved.
4. The lifetime of tempdata is a little bit tricky. It will be available until you read it the first time. After you read it, it will be marked for deletion. So in the next request, it won’t be available. However, you can extend its lifetime by using the keep and peek method.

Readers, did I miss anything? Share your feedback as comments.