ASP.NET State Management in appropriate situations

Question

There are 6 techniques to manage states in ASP.NET 3.5 (as far as I know).

(1) View State
(2) Cross Page Posting
(3) Query String
(4) Session State
(5) Application State
(6) Cookies

Can anyone give me some appropriate examples of situations where I should use these techniques?

For example:

(*) Session State: Personalization, Buy Cart, etc.
(*) Cookies: Saving User Credentials, etc.

Answer 1

There's a lot of factors that can influence this, so I won't comment on all of them. But here are a few pointers:

• ViewState - This is useful when you'll be posting back to the same page frequently (something you're practically forced into doing by ASP.Net Webforms). How useful it is exactly changes depending on what kind of app you're building. For public internet sites, it should be used very sparingly. You may even want to turn it off by default. For local intranet sites, it's a great tool — especially for the fewer, heavier, webforms pages.

• Query String - Use this to store state that you need to allow the user to bookmark a page or process and come back to much later. Even then, you might want to keep it down to some kind of hash that you can use as a key in a database lookup to avoid a really huge url (though hashes have their own problems). Also, a lot of users like to fiddle with your query string directly, so it can be dangerous to put too much here. It's easy to accidentally expose data to users who aren't supposed to see it this way.

• Application State - Remember that this is shared by all users, so use appropriately. Things like view counts can go here.

• Cookies - Don't use cookies to store user credentials. They're just plain unencrypted text files. Use cookies to store a key into the session (even here you can and should now use cookie-less sessions) and simple personalization settings that will be specific to that user and browser. For example, my monitor size at work is different from home, and so putting display size/layout settings into a cookie is nice because the settings stick for each computer, but it isn't going to compromise my security any if someone else reads that information.

Now I want to highlight this concept from the "Query String" section:

you might want to keep it down to some kind of hash that you can use as a key in a database lookup

Again, hashes have their own problems, but I want to point out that several items on my list talk (including Query String) about uploading data from the client web browser to the web server: ViewState, Query String, Cookie, and Cross-Page Post. You want to minimize the data that you move from client to server. This concept applies to all of these, and for several reasons:

1. Pulling data from the client is slow for public internet sites. Even broadband connections typically cripple the bandwidth available for upload. 512Kpbs (still a typical broadband upload rate in many areas) is nothing when compared to the Gigabit Ethernet (or faster) connection that likely sits between your database and your web server. As much as you might think of a database query as slow (and it is), it's still likely a much better way to go than waiting for the same data to arrive from the client.
2. Keeping the data on the server is cheaper, because you don't pay for the bandwidth required to push it to or from the client, and bandwidth often costs as much or more than your server hardware.
3. It's more secure, because if done right even when a client's computer or connection is compromised all the hacker has access to initially is a hash key that likely expires by the time he can decrypt it. Of course, if done wrong he can use that key directly immediately, so you still need to be careful.

So for most things, what I recommend is to start out by keeping a database key in the Session and then have code to easily pull what you need from a database based on that key. As you experience bottlenecks, profile to find out where they are and start caching those pages or controls, or keep that data/query result in the session directly.

Answer 2

State management option

View state:

Use when you need to store small amounts of information for a page that will post back to itself. Using the ViewState property provides functionality with basic security.

Control state:

Use when you need to store small amounts of state information for a control between round trips to the server.

Hidden fields:

Use when you need to store small amounts of information for a page that will post back to itself or to another page, and when security is not an issue.

You can use a hidden field only on pages that are submitted to the server.

Cookies:

Use when you need to store small amounts of information on the client and security is not an issue.

Query string:

Use when you are transferring small amounts of information from one page to another and security is not an issue.

You can use query strings only if you are requesting the same page, or another page via a link.

Server Side Management Options

Application state

Use when you are storing infrequently changed, global information that is used by many users, and security is not an issue. Do not store large quantities of information in application state.

Session state

Use when you are storing short-lived information that is specific to an individual session and security is an issue. Do not store large quantities of information in session state. Be aware that a session-state object will be created and maintained for the lifetime of every session in your application. In applications hosting many users, this can occupy significant server resources and affect scalability.

Profile properties

Use when you are storing user-specific information that needs to be persisted after the user session is expired and needs to be retrieved again on subsequent visits to your application.

Database support

Use when you are storing large amounts of information, managing transactions, or the information must survive application and session restarts. Data mining is a concern, and security is an issue.