0

besides TempData, which I believe isn't the best thing to use nowdays, what are some best practices in how you can persist user data from page to page?

Do you usually just go back to the DB every time...ajax or not...do you make a request every time or do you store it in lets say the Request object or some other in process object instance?

I'm just looking for a broad range of ideas as I am overwhelmed with looking this up on the net...there's a LOT out there and it would be easier for me to get some insight via stack as well.

tereško
  • 58,060
  • 25
  • 98
  • 150
PositiveGuy
  • 46,620
  • 110
  • 305
  • 471
  • 2
    [This question](http://stackoverflow.com/questions/7993263/viewbag-viewdata-and-tempdata) discusses some persistence options in MVC: and it links to [this page which has more detail](http://rachelappel.com/when-to-use-viewbag-viewdata-or-tempdata-in-asp.net-mvc-3-applications). – stuartd Jan 24 '13 at 18:03
  • Have you considered [`SessionState`](http://msdn.microsoft.com/en-us/library/system.web.sessionstate.aspx)? – jrummell Jan 24 '13 at 18:03
  • 1
    @jrummell - I don't understand your answer. The Session property supplied by WebForms and MVC are both using SessionState, so how is that any different? – Erik Funkenbusch Jan 24 '13 at 18:14
  • no I do not like state servers. – PositiveGuy Jan 30 '13 at 02:48

1 Answers1

0

There are several options. If we're talking about intrarequest, then of course ViewBag is the best choice. Intrapage (across requests) then the best choice is probably hidden fields, unless it's sensitive data.

Between pages, then there are several options. You can of course pass data as query string parameters. Session also makes a convenient option, so long as the data size is small, and it's ok if the session gets lost (ie, you can get it again or regenerate it). In certain other situations, you can post data to another page using hidden fields, but this should largely be discouraged since you should prefer to use PRG (Post/Redirect/Get) pattern.

Some other options are using the context cache HttpContext.Cache (Which i feel is misnamed, but oh well) or saving it in temporary tables in the database. Any "in-memory" option will have scalability issues if you decide to move to a web farm (Session can be made to be backed by database, but it slows things down).

It also depends on what data you're talking about. If it's user data, then another option is to store it in a cookie, or to use the user data portion of the Forms Authentication cookie, and create a custom IIdentity object.

Finally, there's just rebuilding the data from its source on every request.

Erik Funkenbusch
  • 92,674
  • 28
  • 195
  • 291