I'm making a simple asp.net app that displays data which can be filtered based on a few different parameters. As such, the different filters that are currently selected need to be saved somewhere. I'm fairly new to .NET, and am wondering the best way to save this information. I noticed a coworker used Request.QueryString in conjunction with the Sessions dictionary. Something like this on page load:
protected void Page_Load(object sender, EventArgs e)
if (Request.QueryString["Category"] != null &&
Request.QueryString["Value"] != null)
string Category = Request.QueryString["Category"];
string CategoryValue = Request.QueryString["Value"];
// selectedFacets is the server side dictionary
protected void exampleCatexampleVal_Button_onClick(object sender, EventArgs e)
Based on your code examples, I understand that you're talking about ASP.NET WebForms. Your use case is not complete, but I'll show here some alternatives to achieve your goal. If you give further information, I'll gladly update my answer.
Before we get to it, let me just put things clear: HTTP is stateless. Understanding this basic rule is very important. It means that your server will receive a request, send it to your app (and the .NET process), get the resulting page (and assets) and send it back to the client (mostly, a browser). End of story. (Almost) Everything that you've created to respond to the request will be lost. And that's why we have options on where to store objects/values across requests.
This is one of the easiest options. You simply call
this.Session.Add("key", object) and it's done. Let's dig into it:
That's another option, and you know it already. You can send data back and forth using the querystring (
You may have heard about it, it's the engine that makes WebForms so lovely (and so hateful). By default, each controller on your page will have its state serialized to the viewstate, which is a huge hidden field with encrypted data on your page. Go on, click "View source" and look for it. Don't scream, please. You may add arbitrary data to the ViewState just like the Session.
So, by now I hope that you have enough information to make your own decision. If I missed anything, please let me know.