Saving values server side vs. using Sessions and Request.QueryString in ASP.net

Question

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
        selectedFacets.Add(Category, CategoryValue);                    
    }
 }

The QueryString here is changed when the user presses a button on the webpage, updating the URL.

My question is why even bother with the QueryString at all when all we're using it for is saving a value server side anyway? Wouldn't just making the button an asp controller be easier, something like:

protected void exampleCatexampleVal_Button_onClick(object sender, EventArgs e) 
{
     selectedFacets.Add(exampleCat, exampleVal);
}

Similar business goes on the with the Sessions dictionary: it's just used to save a bunch of values to variables on the server, so why use it in the first place? I'm sure there's a good reason, but right now they just seems overly complicated for what they do. Thank you!

Answer 1

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.

Server-side Session

This is one of the easiest options. You simply call this.Session.Add("key", object) and it's done. Let's dig into it:

• It will use server resources. That is, the most you use the session, the most memory (and other resources, as needed) your app will consume.
• It will be harder to scale, because data will be on your server memory. Vertical scale may be an option, according to your hardware, but horizontal scale will be limited. You can use a session-server or store session on a SQL Server database, but it won't be so efficient anymore.
• It's attached to your client session. It will be lost if the user opens another browser or sends a link to his friend.
• It's relatively safe. I say relatively because of the options below. At least it's server side.

GET arguments (AKA QueryString)

That's another option, and you know it already. You can send data back and forth using the querystring (?that=stuff&on=the&URL=youKnow).

• It's limited to 2000 characters and that must be serializable. That's why you probably won't put a DataGrid there.
• The user may change it. Be aware! Always sanitize data from the QueryString.
• User is free to bookmark the link or send it to a friend and stuff will be the same. That's nice, mind you.

ViewState

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.

• It's on the client side. Don't trust it.
• It will be send back and forth on each request, so it will consume extra bandwidth.
• It will take time to be deserialized/serialized on each request/response.
• Data must be serializable (you know what I mean).

So, by now I hope that you have enough information to make your own decision. If I missed anything, please let me know.

Answer 2

Have a look at this MSDN Article first. I read through it, and it may answer your question for you.

http://msdn.microsoft.com/en-us/magazine/cc300437.aspx

What you're missing, is how the asp.net page lifecycle works:

http://msdn.microsoft.com/en-us/library/ms178472(v=vs.100).aspx

The thing is, that 'server variable' won't persist between postbacks (AFAIK). It's only useful inside that page, right then. As soon as the page is disposed at the end of the cycle, that dictionary is gone. So you have to store it somewhere if you want to use it later. The article I referenced shows you all the places that you can store information to persist it and where you store it depends on how long you need it to persist, and how many users should have access to it.

Now, certainly, if you DON'T want to persist that dictionary, then sure, just store it the page variable. That's just fine. There's no reason to persist data that you never need again.