Using Tempdata in ASP.NET MVC - Best practice

Question

I am using ASP.NET MVC 3 to build a web application.

What I am trying to do is pass values between two controllers, though there are many ways to do this I am particular interested in using TempData for this.

public ActionResult Action1()
{
    string someMessage;
    Test obj = SomeOperation();
    if(obj.Valid)
    {
        someMessage = obj.UserName;
    }
    else
    {
        someMessage = obj.ModeratorName;
    }

    TempData["message"] = someMessage;

    return RedirectToAction("Index");
}

public ActionResult Index()
{
    ViewBag.Message = TempData["message"]

    return View();
}

So is the use of TempData here correct ? I mean under best programming practices is this correct way of using TempData ?

In what real time cases should TempData be used ?

Note : I have gone through the following links

• When to use TempData vs Session in ASP.Net MVC
• http://www.gregshackles.com/2010/07/asp-net-mvc-do-you-know-where-your-tempdata-is/

Thanks

Chiclayo

Answer 1

TempData is a bucket where you can dump data that is only needed for the following request. That is, anything you put into TempData is discarded after the next request completes. This is useful for one-time messages, such as form validation errors. The important thing to take note of here is that this applies to the next request in the session, so that request can potentially happen in a different browser window or tab.

To answer your specific question: there's no right way to use it. It's all up to usability and convenience. If it works, makes sense and others are understanding it relatively easy, it's good. In your particular case, the passing of a parameter this way is fine, but it's strange that you need to do that (code smell?). I'd rather keep a value like this in resources (if it's a resource) or in the database (if it's a persistent value). From your usage, it seems like a resource, since you're using it for the page title.

Hope this helps.

Copious

m actually using this for displaying a name of the customer I have deleted... for eg : Customer XXX deleted is what I want to display and this XXX I am passing using TempData. Thanks for clearing this for me. – Chiclayo

That means that strictly speaking it's broken, right? If another request happens in-between a post that sets temp data and the subsequent get that relies on it (from another tab, for example), the intermittent request snatches away the tempdata. Not that this is likely to happen, but still. – Weidar

I wouldn't call it broken. Its designed this way for a reason and for cases like Yasser is asking about. If once in a million times your user doesn't get the message "customer was deleted" its not the end of the world, but I even doubt it can ever happen, its too unlikely to consider. – Copious

Do you think keeping a big bunch of files in TempData is good practice? I have 100 newsfeed elements and they are kept in TempData, but I have a feeling that it slows website down. – Zahn

I don't think its a good practice. I'd define some structure of my own and would keep it there. In your shoes I'd measure performance having multiple items in tempdata, your own structure and having your own structure in tempdata as 1 item. There's no right and wrong way, but to make your measurements and using what works, performing and is easy to understand – Copious

Answer 2

Please note that MVC 3 onwards the persistence behavior of TempData has changed, now the value in TempData is persisted until it is read, and not just for the next request.

The value of TempData persists until it is read or until the session times out. Persisting TempData in this way enables scenarios such as redirection, because the values in TempData are available beyond a single request. https://msdn.microsoft.com/en-in/library/dd394711%28v=vs.100%29.aspx

Eriha

Answer 3

Just be aware of TempData persistence, it's a bit tricky. For example if you even simply read TempData inside the current request, it would be removed and consequently you don't have it for the next request. Instead, you can use Peek method. I would recommend reading this cool article:

MVC Tempdata , Peek and Keep confusion

Blastogenesis