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

Not sure if you mean the Cache object by Application State.

The Cache object is a great way to manage application wide state, e.g. to record source and count access to your website (to prevent DDOS attacks for example).

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.

Answer 3

(3) Query String (4) Session State (5) Application State (6) Cookies

1. Viewstate

• Disclaimer: Use as little as possible. Good point is to always have each state reachable by an url, if possible.
  • F.e. Paging should use the URL (so /url/?p=2 instead of storing the page in Viewstate)
• Use to persist control state between page-cycles.
  • F.e. Store the selected item in a checkbox, so you can determine whether it has changed.

2. Cross Page Posting

Don't. See the disclaimer for viewstate. Use the URL for this, or store the data in a session / cookie / profile if loads of properties need to be kept around.

Major downside of CPP is that the user cannot use the 'Back' and 'Forward' buttons in it's webbrowser. When a user clicks the back button it wants to undo everything on that page and retry the last one. When using CPP to click them through a wizard; this behavior is not possible without a lot of 'Are you sure you want to resend blablablabl'.

3. Query String

Use alot. Every visible state that a page could reach should be accessible by URL. People with screenreaders will thank you for this. And by using the query string there is no need to use javascript-only solutions.

/url/?page=2    // when doing paging, don't use postback for this
/url/?tab=advanced-search    // when having tabs on top of your page

etc.

4. Session state

Use this for short-living objects, that only make sense this time the visitor visits your site. For example:

• Which step of a certain wizard was reached
• Pages a user had visited before
• Small objects you want to put in cache, but that are user-bound

Don't use sessions but profiles for things like:

• Preferences
• Selected language

Because those things also make sense the next time the user visits your site.

5. Application state

Never. Use ASP.NET cache, or memcached, or any caching framework for this.

6. Cookies

Session ID, Profile ID for authenticated users; user preferences for anonymous users (everything listed in the second list under 4.).