I\'ve got a Controller, and in one of the ActionResult
s, there is a javascript value being returned that I can access via:
Request.QueryString[
HTTP is stateless, every request has it's own state and Controller instance.
You can use TempData
which use Session
but delete the value after you read it.
When you say ActionResult
, I assume you mean your Action methods within the controller that return Actionresult
s? e.g.:
public class HomeController : Controller {
// GET: /Home/
public ActionResult Index() {
var freq = Request.QueryString["frequency"];
// ** Want to persist freq here **
HomeIndexViewModel model = FooLogic.BarIndex();
return View();
}
// GET: /Home/Detail
public ActionResult Detail() {
var freq = **Want to access freq here**;
HomeDetailViewModel model = FooLogic.BarDetail(freq);
return View();
}
}
As your question refers to ActionResult, this could be any kind of ActionResult - without knowing exactly what you are doing this answer outlines a general approach to choosing a state persistence store.
The key questions to ask yourself are:
Your options for data persistence are many and varied, each fulfilling a slightly different role, though many overlap with others in their potential use (e.g. Session
and TempData
). I've listed many of them below, all of which could solve your problem depending on the exact scenario. The first two (View-persisted data or TempData) are most likely to be useful for you, but in the absence of more information others may actually be the ones you need.
There used to be at least Nine Options for Managing Persistent User State in ASP.NET, and many of those still apply in MVC.
An example of this would be to pass your freq
variable into the View for the Index method (for instance by using ViewBag.Frequency = freq;
, and then use it with @Html.ActionLink. E.g.:
@Html.ActionLink("Click for the Next Action", "Detail", "Home",
new { frequency = ViewBag.Frequency }, null)
Your Detail action then becomes:
public ActionResult Detail(int frequency) { ...
Similar approaches would allow you to use the value in hidden form fields, or in javascript for future AJAX requests by setting a javascript variable using var freq = @Html.Raw(Viewbag.Frequency);
, for instance.
Note: There is a school of thought (which I think is a good one) that you shouldn't be using these, instead you should create a strongly typed class (such as the above HomeIndexViewModel
) for the Model for each view to allow you to better test your Controller Actions and Views.
Advantages of ViewData
/ViewBag
:
Disadvantages:
SessionStateTempDataProvider
(see the documentation)Ostensibly this is designed to do exactly what you want, but there are considerations.
This has all the same considerations as TempData
, but you choose when to delete the value from the Session
. It is really intended for general information relevant to the current session (e.g. a simple shopping cart that the user wouldn't expect to see if they close and reopen the browser, or visit the site on their mobile phone later on).
You can access this through the HttpContext property of your Controller. E.g.:
HttpContext.Cache["Frequency"] = freq;
Cookies are often overlooked as state persistence - but they are very useful for some kinds of data. Remember that if the user expects to see data associated with a user identity, then the cookie won't help if they log in on another computer, use an Incognito/Private browser session etc.
Databases are the daddy of state persistence. Your application code should be viewed as volatile, and able to deal with restarts, web farm scenarios etc. etc. If you want to store data, use a database. By "Database" I mean a data persistence medium in any form, from SQL Server to Redis, Azure file storage, Azure table storage, Amazon S3 etc.
There are other options, they are not commonly as commonly used though. For instance, you can implement your own caching (example here), or use ...
Theoretically you'll never use these (unless this is a 10-minute application for a demo to your colleagues):
The times you need instance fields on a controller are when providing common services to all actions, such as IoC interfaces, but these are not storing state within or across requests.
Cache