CHAPTER-4 State Management

4.0 ASP.NET State Management

4.1 View State
4.11 Storing Objects in View State
4.12 Assessing View State
4.2 The Query String
4.21 Cross-Page Posting and Validation
4.22 Cookies (create, set, add and expire cookie)
4.3 Session State
4.31 Session Architecture
4.32 Using Session State(HttpSessionState Members)
4.4 Application State


ASP.NET State Management
ASP.NET includes a variety of options for state management. It features the same Session and
Application state collections as traditional ASP (with a few enhancements) and an entirely new
view state model.
ASP.NET even includes a caching system that allows you to retain information without
sacrificing server scalability.

View State
View state should be your first choice for storing information within the bounds of a single page.
View state is used natively by the ASP.NET web controls. It allows them to retain(hold) their
properties between postbacks.
It has a built-in page property called ViewState, So that You can add your own data to the view
state collection.
The type of information you can store includes simple data types and your own custom objects.
View state relies on a dictionary collection, where each item is indexed with a unique string
name. For example, consider this code:

ViewState("Counter") = 1

When retrieving a value, you use the key name. You also need to cast the retrieved value to the
appropriate data type. This extra step is required because the ViewState collection stores all items
as standard objects, which allows it to handle many different data types.
Heres the code that retrieves the counter from view state and converts it to an integer:

Dim counter As Integer
If ViewState("Counter") IsNot Nothing Then
counter = CInt(ViewState("Counter"))
End If

If you attempt to look up a value that isnt present in the collection, youll receive a
NullReferenceException. To defend against this possibility, you should check for a null value
before you attempt to retrieve and cast data that may not be present.

A View State Example
The following code demonstrates a page that uses view state. It allows the user to save a set of
values (all the text thats displayed in all the text boxes of a table) and restore it later. This
example uses recursive logic to dig through all child controls, and it uses the control ID for the
view state key, because this is guaranteed to be unique in the page.

Public partial Class ViewStateTest
Inherits System.Web.UI.Page
Protected Sub cmdSave_Click(ByVal sender As Object, ByVal e As
System.EventArgs)
' Save the current text.
SaveAllText(Table1.Controls, True)
End Sub

Private Sub SaveAllText(ByVal controls As ControlCollection,
ByVal saveNested As Boolean)
For Each control As Control In controls
If TypeOf control Is TextBox Then
' Store the text using the unique control ID.
ViewState(control.ID) = (CType(control, TextBox)).Text
End If
If (control.Controls IsNot Nothing) AndAlso saveNested
Then
SaveAllText(control.Controls, True)
End If
Next control
End Sub

Protected Sub cmdRestore_Click(ByVal sender As Object,
ByVal e As System.EventArgs)
' Retrieve the last saved text.
RestoreAllText(Table1.Controls, True)
End Sub

Private Sub RestoreAllText(ByVal controls As ControlCollection,
ByVal saveNested As Boolean)
For Each control As Control In controls
If TypeOf control Is TextBox Then
If ViewState(control.ID) IsNot Nothing Then
CType(control, TextBox).Text =
CStr(ViewState(control.ID))
End If
End If
If (control.Controls IsNot Nothing) AndAlso
saveNested Then
RestoreAllText(control.Controls, True)
End If
Next control
End Sub
End Class



Disadvantage
One of the most significant limitations with view state is that its tightly bound to a specific page.
If the user navigates to another page, this information is lost. This problem has several solutions,
and the best approach depends on your requirements.

The Query String
One common approach is to pass information using a query string in the URL. You will
commonly find this approach in search engines.
For example, if you perform a search on the Google website, youll be redirected to a new URL
that incorporates your search parameters. Heres an example:

http://www.google.ca/search?q=organic+gardening

The query string is the portion of the URL after the question mark. In this case, it defines a single
variable named q, which contains the organic+gardening string.
The advantage of the query string is that its lightweight and doesnt exert any kind of burden on
the server. Unlike cross-page posting, the query string can easily transport the same information
from page to page.

It has some limitations, however:
Information is limited to simple strings, which must contain URL-legal characters.
Information is clearly visible to the user and to anyone else who cares to eavesdrop on the
Internet.
The enterprising user might decide to modify the query string and supply new values, which
your program wont expect and cant protect against.
Many browsers impose a limit on the length of a URL (usually from 1 to 2 KB). For that reason,
you cant place a large amount of information in the query string and still be assured of
compatibility with most browsers.
A list of items corresponding to records in a database, like products. The user can then select an
item and be forwarded to another page with detailed information about the selected item.

Using the Query String
To store information in the query string, you need to place it there yourself. Unfortunately, there
is no collection-based way to do this. Typically, this means using a special HyperLink control, or
you can use a Response.Redirect() statement like the one shown here:

' Go to newpage.aspx. Submit a single query string argument
' named recordID, and set to 10.
Dim recordID As Integer = 10
Response.Redirect("newpage.aspx?recordID=" & recordID.ToString())

You can send multiple parameters as long as you separate them with an ampersand (&), as shown
here:

' Go to newpage.aspx. Submit two query string arguments:
' recordID (10) and mode (full).
Response.Redirect("newpage.aspx?recordID=10&mode=full")

The receiving page has an easier time working with the query string. It can receive the values
from the QueryString dictionary collection exposed by the built-in Request object, as shown here:

Dim ID As String = Request.QueryString("recordID")

Note that information is always retrieved as a string, which can then be converted to another
simple data type. Values in the QueryString collection are indexed by the variable name.

URL Encoding
One potential problem with the query string is using characters that arent allowed in a URL. The
list of characters that are allowed in a URL is much shorter than the list of allowed characters in
an HTML document. All characters must be alphanumeric or one of a small set of special
characters, including $-_.+!*'(),. Some browsers tolerate certain additional special characters
(Internet Explorer is notoriously lax), but many do not.
If youre concerned that the data you want to store in the query string may not consist of URL
legal characters, you should use URL encoding. With URL encoding, special characters are
replaced by escaped character sequences starting with the percent sign (%), followed by a two-
digit hexadecimal representation.
For example, the space becomes %20.
You can use the methods of the HttpServerUtility class to encode your data automatically. For
example, the following shows how you would encode a string of arbitrary data for use in the
query string. This replaces all the nonlegal characters with escaped character sequences.

Dim productName As String = "Flying Carpet"
Response.Redirect("newpage.aspx?productName=" &
Server.UrlEncode(productName))

And heres how you could decode the same information:

Dim ID As String = Server.UrlDecode(Request.QueryString("recordID"))
Cross-Page Posting and Validation
Cross-page posting introduces a few wrinkles when you use it in conjunction with the validator
Controls.
When you use the validator controls, you need to check the Page.IsValid property to ensure that
the data the user entered is correct.
Although users are usually prevented from posting invalid pages back to the server (thanks to
some slick client-side JavaScript), this isnt always the case. For example, the client browser
might mnot support JavaScript, or a malicious user could deliberately circumvent the client-side
validation checks.
When you use validation in a cross-page posting scenario, the potential for some trouble exists.
Namely, what happens if you use a cross-page postback and the source page has validation
controls?
An example with a RequiredFieldValidator that requires input in a text box.



If you click one of the buttons to perform the cross-page postback (both of which have
CausesValidation set to True), youll be prevented by the browsers client-side checks. Instead,
the error message will appear. However, you should also check what happens when client-side
scripting isnt supported by setting the RequiredFieldValidator.EnableClientScript property to
False. (You can change it back to True once you perfect your code.) Now when you click one of
the buttons, the page is posted back, and the new page appears.
To prevent this from happening, you obviously need to check the validity of the source page in
the target page before you perform any other action by examining Page.IsValid. This is the
standard line of defense used in any web form that employs validation. The difference is that if
the page isnt valid, its not sufficient to do nothing. Instead, you need to take the extra step of
returning the user to the original page. Heres the code you need:

Protected Sub Page_Load(ByVal sender As Object, ByVal e As EventArgs)
If PreviousPage IsNot Nothing Then
If (Not PreviousPage.IsValid) Then
' Display an error message or just do nothing.
Else
...
End If
End If
End Sub
Custom Cookies
Custom cookies provide another way you can store information for later use.
Cookies are small files that are created on the clients hard drive (or, if theyre temporary, in the
web browsers memory).

One advantage of cookies is that they work transparently without the user being aware that
information needs to be stored. They also can be easily used by any page in your application and
even retained between visits, which allows for truly long-term storage.

They suffer from some of the same drawbacks that affect query strings. Namely, theyre limited
to simple string information, and theyre easily accessible and readable if the user finds and opens
the corresponding file. These factors make them a poor choice for complex or private information
or large amounts of data.

Before you can use cookies, you should import the System.Net namespace so you can easily work
with the appropriate types, as shown here:

Imports System.Net

Cookies are fairly easy to use. Both the Request and Response objects (which are provided
through Page properties) provide a Cookies collection.

The important trick to remember is that
you retrieve cookies from the Request object, and
you set cookies using the Response object.

To set a cookie, just create a new System.Net. HttpCookie object. You can then fill it with string
information (using the familiar dictionary pattern) and attach it to the current web response, as
follows:

' Createthe cookie object.
Dim cookie As New HttpCookie("Preferences")

' Set a value in it.
cookie("LanguagePref") = "English"

' Add it to the current web response.
Response.Cookies.Add(cookie)

A cookie added in this way will persist until the user closes the browser and will be sent with
every request. To create a longer-lived cookie, you can set an expiration date, as shown here:

' This cookie lives for one year.
cookie.Expires = DateTime.Now.AddYears(1)

Cookies are retrieved by cookie name using the Request.Cookies collection, as shown here:

Dim cookie As HttpCookie = Request.Cookies("Preferences")

' Check to see whether a cookie was found with this name.
' This is a good precaution to take,
' because the user could disable cookies,
' in which case the cookie will not exist.
Dim language As String
If cookie Is Not Nothing Then
language = cookie("LanguagePref")
End If

The only way to remove a cookie is by replacing it with a cookie that has an expiration date that
has already passed. The following code demonstrates this technique:

Dim cookie As New HttpCookie("LanguagePref")
cookie.Expires = DateTime.Now.AddDays(-1)
Response.Cookies.Add(cookie)

Session State
Session state is the heavyweight of state management.
It allows information to be stored in one page and accessed in another, and it supports any type of
object, including your own custom data types. Best of all, session state uses the same collection
syntax as view state.
The only difference is the name of the built-in page property, which is Session.
Every client that accesses the application has a different session and a distinct collection of
information.
Session state is ideal for storing information such as the items in the current users shopping
basket when the user browses from one page to another.
But session state doesnt come for free. Though it solves many of the problems associated with
other forms of state management, it forces the web server to store additional information in
memory. This extra memory requirement, even if it is small, can quickly grow to performance-
destroying levels as hundreds or thousands of clients access the site.

Session Architecture

ASP.NET session state architecture
Session management is not part of the HTTP standard. As a result, ASP.NET needs to do some
extra work to track session information and bind it to the appropriate response.
ASP.NET tracks each session using a unique 120-bit identifier.
ASP.NET uses a proprietary algorithm to generate this value.
So that a malicious user cant guess what session ID a given client will be using. This ID is the
only piece of information that is transmitted between the web server and the client.
When ASP.NET handles an HTTP request, it flows through a pipeline of different modules that
can react to application events.
One of the modules in this chain is the SessionStateModule (in the System.Web.SessionState
namespace).
The SessionStateModule generates the session ID, retrieves the session data from external state
providers, and binds the data to the call context of the request.
It also saves the session state information when the page is finished processing.
However, its important to realize that the SessionStateModule doesnt actually store thesession
data. Instead, the session state is persisted in external components, which are named state
providers.

Using Session State
You can interact with session state using the System.Web.SessionState.HttpSessionState class,
which is provided in an ASP.NET web page as the built-in Session object.
The syntax for adding items to the collection and retrieving them is basically the same as for
adding items to the view state of a page.
For example, you might store a DataSet in session memory like this:

Session("ds") = ds

You can then retrieve it with an appropriate conversion operation:

ds = Ctype(Session("ds"),DataSet)

Session state is global to your entire application for the current user. Session state can be lost in
several ways:
If the user closes and restarts the browser.
If the user accesses the same page through a different browser window, although the session
will still exist if a web page is accessed through the original browser window. Browsers differ
on how they handle this situation.
If the session times out because of inactivity. By default, a session times out after 20 idle
minutes.
If the programmer ends the session by calling Session.Abandon().

In the first two cases, the session actually remains in memory, because the web server has no idea
that the client has closed the browser or changed windows. The session will linger in memory,
remaining inaccessible, until it eventually expires.
In addition, session state will be lost when the application domain is re-created. This process
happens transparently when you update your web application or change a configuration setting.
The application domain may also be recycled periodically to ensure application health.
If this behavior is causing a problem, you can store session state information out of process,
Without-of-process state storage, the session information is retained even when the application
domain is shut down.

HttpSessionState Members

Application State
Application state allows you to store global objects that can be accessed by any client.
Application state is based on the System.Web.HttpApplicationState class, which is
provided in all web pages through the built-in Application object.
Application state is similar to session state. It supports the same type of objects, retains
information on the server, and uses the same dictionary-based syntax.
A common example with application state is a global counter that tracks how many times
an operation has been performed by all of the web applications clients.
For example, you could create a global.asax event handler that tracks how many sessions have
been created or how many requests have been received into the application. Or you can use
similar logic in the Page.Load event handler to track how many times a given page has been
requested by various clients. Heres an example of the latter:

Protected Sub Page_Load(ByVal sender As Object, ByVal e As EventArgs)
Dim count As Integer =
CInt(Application("HitCounterForOrderPage"))
count += 1
Application("HitCounterForOrderPage") = count
lblCounter.Text = count.ToString()
End Sub
Once again, application state items are stored as objects, so you need to cast them when you
retrieve them from the collection. Items in application state never time out. They last until the
application or server is restarted or until the application domain refreshes itself (because of
automatic process-recycling settings or an update to one of the pages or components in the
application).
Application state isnt often used, because its generally inefficient. In the previous example, the
counter would probably not keep an accurate count, particularly in times of heavy traffic. For
example, if two clients requested the page at the same time, you could have a sequence of events
like this:

1. User A retrieves the current count (432).
2. User B retrieves the current count (432).
3. User A sets the current count to 433.
4. User B sets the current count to 433.

In other words, one request isnt counted because two clients access the counter at the same time.
To prevent this problem, you need to use the Lock() and Unlock() methods, which explicitly
allow only one client to access the Application state collection at a time, as follows:

Protected Sub Page_Load(ByVal sender As Object, ByVal e As EventArgs)
' Acquire exclusive access.
Application.Lock()
Dim count As Integer =
CInt(Application("HitCounterForOrderPage"))
count += 1
Application("HitCounterForOrderPage") = count
' Release exclusive access.
Application.Unlock()
lblCounter.Text = count.ToString()
End Sub

Application state information is always stored in process. This means you can use any .NET data
types. However, it also introduces the same two limitations that affect in-process session state.
Namely, you cant share application state between the servers in a web form, and you will always
lose your application state information when the application domain is restarted.








a KASHYAP KIKUBHAI PATEL presentation