TempData - Good Practice or better to avoid?

In the only really big Asp.Net MVC application I did so far, I was required not to use anything using the Session.
As TempData uses session, I tried figuring out TempData CookieProvider (was like a year back though) and just could not get it to work in our project setup. (Others also tried and failed).
So we went and built the whole system avoiding TempData completely.

I'm moving on to other projects now, and seems the above project gave me an aversion to using TempData.
From my point, I can see it being useful messages (feedback) to the View at best.
Though I did not look into Azure, I do have a project coming up that will end up in the cloud, and not even sure how well session dependent functionality will work on that.

Is it just me? I've seen some code that put full models into TempData and then redirect to another action method which is pretty scare (imo).

I found a situation that required me to use TempData. My master view was checking its ViewData to see if there was a message that it should display to the user in an alert box. This allowed me to display modal messages to the user no matter what view they were looking at. I found that, if I stored a message in ViewData and then redirected to another action, my message wasn't displayed. That was because the second action started with a fresh ViewData. I had to put the message into TempData so that it would survive the redirection. That would be why you're seeing people putting models into TempData.

I would suggest that TempData only be used when it's required, i.e. a typed Model should be your first option, then ViewData, then TempData.

I've found another situation where TempData was needed and it involved implementing the follwing patern,

http://en.wikipedia.org/wiki/Post/Redirect/Get

I'm not fuly converted to this method yet but it did solve the problem highlighted below.

http://stackoverflow.com/questions/2...957866#2957866

That's exactly why TempData is my only way out..following the PRG pattern! (which is a must)

The thing is TempData by default saved in Session and by default Session is Inproc Session which is saved in Server Memory. You have to use outproc Session State, either use Sql Server or State Server if you are hosting in a web farm. Not that great for performance. (But then, I might be completely off here)

"A typical use for a TempDataDictionary object is to pass data from an action method when it redirects to another action method. For example, an action method might store information about an error in the controller's TempData property (which returns a TempDataDictionary object) before it calls the RedirectToAction method. The next action method can then handle the error and render a view that displays an error message." (http://msdn.microsoft.com/en-us/libr...ictionary.aspx)

So thats what it is there for. If you dont like it being stored in session you can override the storage provider.

"It depends on current TempData-provider (class that implements ITempDataProvider interface). By default, SessionStateTempDataProvider is used so by default TempData is stored into session. But you can implement your own TempData-provider. Then you should assign instance of this TempData-provider into TempDataProvider property in overrided Controller.Initialize method."

http://forums.asp.net/t/1473413.aspx

Pino