Web pages rarely be stand alone. Web
applications almost always need to track users who visits multiple
pages, whether to provide personalization, store information about a
user or to track usage for reporting purposes.
Purpose
State management is the process by which you maintain state and page
information over multiple requests for the same or different pages.
Types of State Management
There are 2 types State Management:
1. Client – Side State Management
This stores information on the client's computer by embedding the
information into a Web page, a uniform resource locator(url), or a
cookie. The techniques available to store the state information at the
client end are listed down below:
a. View State – Asp.Net uses View State to track the values in the
Controls. You can add custom values to the view state. It is used by the
Asp.net page framework to automatically save the values of the page and
of each control just prior to rendering to the page. When the page is
posted, one of the first tasks performed by page processing is to
restore view state.
b. Control State – If you create a custom control that requires view
state to work properly, you should use control state to ensure other
developers don’t break your control by disabling view state.
c. Hidden fields – Like view state, hidden fields store data in an
HTML form without displaying it in the user's browser. The data is
available only when the form is processed.
d. Cookies – Cookies store a value in the user's browser that the
browser sends with every page request to the same server. Cookies are
the best way to store state data that must be available for multiple Web
pages on a web site.
e. Query Strings - Query strings store values in the URL that are
visible to the user. Use query strings when you want a user to be able
to e-mail or instant message state data with a URL.
2. Server – Side State Management
a. Application State - Application State information is available to all pages, regardless of which user requests a page.
b. Session State – Session State information is available to all pages opened by a user during a single visit.
Both application state and session state information is lost when
the application restarts. To persist user data between application
restarts, you can store it using profile properties.
Implementation Procedure
Client – Side State Management:
View State:
The ViewState property provides a dictionary object for retaining
values between multiple requests for the same page. When an ASP.NET page
is processed, the current state of the page and controls is hashed into
a string and saved in the page as a hidden field. If the data is too
long for a single field, then ASP.NET performs view state chunking (new
in ASP.NET 2.0) to split it across multiple hidden fields. The following
code sample demonstrates how view state adds data as a hidden form
within a Web page’s HTML:
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE” value="/wEPDwUKMTIxNDIyOTM0Mg9kFgICAw9kFgICAQ8PFgIeBFRleHQFEzQvNS8yMDA2IDE6Mzc6MTEgUE1kZGROWHn/rt75XF/pMGnqjqHlH66cdw==" />
Encrypting of the View State: You can enable view state encryption
to make it more difficult for attackers and malicious users to directly
read view state information. Though this adds processing overhead to the
Web server, it supports in storing confidential information in view
state. To configure view state encryption for an application does the
following:
<Configuration>
<system.web>
<pages viewStateEncryptionMode="Always"/>
</system.web>
</configuration>
Alternatively, you can enable view state encryption for a specific
page by setting the value in the page directive, as the following sample
demonstrates:
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" ViewStateEncryptionMode="Always"%>
View State is enabled by default, but if you can disable it by
setting the EnableViewState property for each web control to false. This
reduces the server processing time and decreases page size.
Reading and Writing Custom View State Data:
If you have a value that you’d like to keep track of while the user
is visiting a single ASP.NET Web page, adding a custom value to
ViewState is the most efficient and secure way to do that. However,
ViewState is lost if the user visits a different Web page, so it is
useful only for temporarily storing values.
Example: Determine the time of last visit to the page
// Check if View State object exists, and display it if it does
If (ViewState ["lastVisit"]!= null)
Label1.Text = (string)ViewState["lastVisit"]; else
Label1.Text = "lastVisit ViewState not defined.";
// Define the ViewState object for the next page view ViewState.Add("lastVisit", DateTime.Now.ToString());
Control State: If you create a custom control that
requires ViewState, you can use the ControlState property to store state
information for your control. ControlState allows you to persist
property information that is specific to a control and cannot be turned
off like the ViewState property. To use control state in a custom
control, your control must override the OnInit method and call the
Register-RequiresControlState method during initialization and then
override the SaveControl-State and LoadControlState methods.
Hidden fields: ViewState stores information in the
Web page using hidden fields. Hidden fields are sent back to the server
when the user submits a form; however, the information is never
displayed by the Web browser (unless the user chooses to view the page
source). ASP.NET allows you to create your own custom hidden fields and
store values that are submitted with other form data. A HiddenField
control stores a single variable in its Value property and must be
explicitly added to the page. You can use hidden fields only to store
information for a single page, so it is not useful for storing session
data. If you use hidden fields, you must submit your pages to the server
using Hypertext Transfer Protocol (HTTP) POST (which happens if the
user presses a button) rather than requesting the page using HTTP GET
(which happens if the user clicks a link). Unlike view state data,
hidden fields have no built-in compression, encryption, hashing, or
chunking, so users can view or modify data stored in hidden fields.
Cookies: Web applications can store small pieces of
data in the client’s Web browser by using cookies. A cookie is a small
amount of data that is stored either in a text file on the client file
system (if the cookie is persistent) or in memory in the client browser
session (if the cookie is temporary). The most common use of cookies is
to identify a single user as he or she visits multiple Web pages.
Reading and Writing Cookies:
A Web application creates a cookie by sending it to the client as a
header in an HTTP response. The Web browser then submits the same cookie
to the server with every new request.
Create a cookie -> add a value to the Response.Cookies HttpCookieCollection.
Read a cookie -> read values in Request.Cookies.
Example:
// Check if cookie exists, and display it if it does
if (Request.Cookies["lastVisit"] != null) // Encode the cookie in case the cookie contains client-side script Label1.Text = Server.HtmlEncode(Request.Cookies["lastVisit"].Value);
else Label1.Text = "No value defined";
// Define the cookie for the next visit Response.Cookies["lastVisit"].Value = DateTime.Now.ToString();Response.Cookies["lastVisit"].Expires = DateTime.Now.AddDays(1);
If you do not define the Expires property, the browser stores it in
memory and the cookie is lost if the user closes his or her browser.
To delete a cookie, overwrite the cookie and set an expiration date
in the past. You can’t directly delete cookies because they are stored
on the client’s computer.
Controlling the Cookie Scope: By default, browsers won’t send a
cookie to a Web site with a different hostname. You can control a
cookie’s scope to either limit the scope to a specific folder on the Web
server or expand the scope to any server in a domain. To limit the
scope of a cookie to a folder, set the Path property, as the following
example demonstrates:
Example:
Response.Cookies["lastVisit"].Path = "/Application1";
Through this the scope is limited to the “/Application1” folder that
is the browser submits the cookie to any page with in this folder and
not to pages in other folders even if the folder is in the same server.
We can expand the scope to a particular domain using the following
statement:
Example:
Response.Cookies[“lastVisit”].Domain = “Contoso”;
Storing Multiple Values in a Cookie:
Though it depends on the browser, you typically can’t store more
than 20 cookies per site, and each cookie can be a maximum of 4 KB in
length. To work around the 20-cookie limit, you can store multiple
values in a cookie, as the following code demonstrates:
Example:
Response.Cookies["info"]["visit"].Value = DateTime.Now.ToString();
Response.Cookies["info"]["firstName"].Value = "Tony";
Response.Cookies["info"]["border"].Value = "blue";
Response.Cookies["info"].Expires = DateTime.Now.AddDays(1);
Running the code in this example sends a cookie with the following value to the Web browser:
(visit=4/5/2006 2:35:18 PM) (firstName=Tony) (border=blue)
Query Strings: Query strings are commonly used to
store variables that identify specific pages, such as search terms or
page numbers. A query string is information that is appended to the end
of a page URL. A typical query string might look like the following
real-world example:
http://support.microsoft.com/Default.aspx?kbid=315233
In this example, the URL identifies the Default.aspx page. The query
string (which starts with a question mark [?]) contains a single
parameter named “kbid,” and a value for that parameter, “315233.” Query
strings can also have multiple parameters, such as the following
real-world URL, which specifies a language and query when searching the
Microsoft.com Web site:
http://search.microsoft.com/results.aspx?mkt=en-US&setlang=en-US&q=hello+world
Value Name | ASP.NET Object | Value
mkt | Request.QueryString[“mkt”] | en-US
setlang | Request.QueryString[“setlang”] | en-US
q | Request.QueryString[“q”] | hello world
Limitations for Query Strings:
1. Some Browsers and client devices impose a 2083 – character limit on the length of the URL.
2. You must submit the page using an HTTP GET command in order for
query string values to be available during page processing. Therefore,
you shouldn’t add query strings to button targets in forms.
3. You must manually add query string values to every hyperlink that the user might click.
Example:
Label1.Text = "User: " + Server.HtmlEncode(Request.QueryString["user"]) +
", Prefs: " + Server.HtmlEncode(Request.QueryString["prefs"]) +
", Page: " + Server.HtmlEncode(Request.QueryString["page"]);
Server - Side State Management:
Application State: ASP.NET allows you to save values
using application state, a global storage mechanism that is accessible
from all pages in the Web application. Application state is stored in
the Application key/value dictionary. Once you add your
application-specific information to application state, the server
manages it, and it is never exposed to the client. Application state is a
great place to store information that is not user-specific. By storing
it in the application state, all pages can access data from a single
location in memory, rather than keeping separate copies of the data.
Data stored in the Application object is not permanent and is lost any
time the application is restarted.
ASP.NET provides three events that enable you to initialize
Application variables (free resources when the application shuts down)
and respond to Application errors:
a. Application_Start: Raised when the application starts. This is the perfect place to initialize Application variables.
b. Application_End: Raised when an application shuts down. Use this to free application resources and perform logging.
c. Application_Error: Raised when an unhandled error occurs. Use this to perform error logging.
Session State: ASP.NET allows you to save values using
session state, a storage mechanism that is accessible from all pages
requested by a single Web browser session. Therefore, you can use
session state to store user-specific information. Session state is
similar to application state, except that it is scoped to the current
browser session. If different users are using your application, each
user session has a different session state. In addition, if a user
leaves your application and then returns later after the session timeout
period, session state information is lost and a new session is created
for the user. Session state is stored in the Session key/value
dictionary.
You can use session state to accomplish the following tasks:
i. Uniquely identify browser or client-device requests and map them
to individual session instances on the server. This allows you to track
which pages a user saw on your site during a specific visit.
ii. Store session-specific data on the server for use across
multiple browser or client-device requests during the same session. This
is perfect for storing shopping cart information.
iii. Raise appropriate session management events. In addition, you can write application code leveraging these events.
ASP.NET session state supports several different storage options for session data:
a. InProc Stores session state in memory on the Web server. This is
the default, and it offers much better performance than using the
ASP.NET state service or storing state information in a database server.
InProc is fine for simple applications, but robust applications that
use multiple Web servers or must persist session data between
application restarts should use State Server or SQLServer.
b. StateServer Stores session state in a service called the ASP.NET
State Service. This ensures that session state is preserved if the Web
application is restarted and also makes session state available to
multiple Web servers in a Web farm. ASP.NET State Service is included
with any computer set up to run ASP.NET Web applications; however, the
service is set up to start manually by default. Therefore, when
configuring the ASP.NET State Service, you must set the startup type to
Automatic.
c. SQLServer Stores session state in a SQL Server database. This
ensures that session state is preserved if the Web application is
restarted and also makes session state available to multiple Web servers
in a Web farm. On the same hardware, the ASP.NET State Service
outperforms SQLServer. However, a SQL Server database offers more robust
data integrity and reporting capabilities.
d. Custom Enables you to specify a custom storage provider. You also need to implement the custom storage provider.
e. Off Disables session state. You should disable session state if you are not using it to improve performance.
Advantages
Advantages of Client – Side State Management:
1. Better Scalability: With server-side state management, each
client that connects to the Web server consumes memory on the Web
server. If a Web site has hundreds or thousands of simultaneous users,
the memory consumed by storing state management information can become a
limiting factor. Pushing this burden to the clients removes that
potential bottleneck.
2. Supports multiple Web servers: With client-side state management,
you can distribute incoming requests across multiple Web servers with
no changes to your application because the client provides all the
information the Web server needs to process the request. With
server-side state management, if a client switches servers in the middle
of the session, the new server does not necessarily have access to the
client’s state information. You can use multiple servers with
server-side state management, but you need either intelligent
load-balancing (to always forward requests from a client to the same
server) or centralized state management (where state is stored in a
central database that all Web servers access).
Advantages of Server – Side State Management:
1. Better security: Client-side state management information can be
captured (either in transit or while it is stored on the client) or
maliciously modified. Therefore, you should never use client-side state
management to store confidential information, such as a password,
authorization level, or authentication status.
2. Reduced bandwidth: If you store large amounts of state management
information, sending that information back and forth to the client can
increase bandwidth utilization and page load times, potentially
increasing your costs and reducing scalability. The increased bandwidth
usage affects mobile clients most of all, because they often have very
slow connections. Instead, you should store large amounts of state
management data (say, more than 1 KB) on the server.
Reference URLs
#. www.awprofessional.com/articles/article.asp?p=31842
#. www.microsoft.com/.../shared/asp/view.asp?url=/seminar/en/20050201_statemanagement/manifest.xml&rate=2
#. scottwater.com/blog/archive/asp-net-state-management-tips/
#. aspalliance.com/1066_Session_State_Management
