MCAD/MCSD Notes: Chapter 3, Lesson 3; Maintaining State Information

Lesson 3: Maintaining State Information

The purpose of this lesson is to introduce stateful web programming to former VB6 users, to reassure ASP "classic" programmers that ASP.NET backwards compatibility is robust and other stuff beyond my scope of awareness.

These are the "levels of state": Context.Handler object state, Query strings state, Cookies state, View state, Session state and Application state.

"...when navigating between Web forms using the Transfer or Execute method, you can retrieve read-only properties from the previous Web form..."

This is done with the Context.Handler object. For more information about this design pattern, see MSDN article "Passing Values Between Web Forms Pages" here:

http://msdn.microsoft.com/library/
    en-us/vbcon/html/vbtskpassingvaluesbetweenwebformspages.asp

It may help the reader to mention that the Context object is a member of the Page object when the Page object was first introduced in Chapter 3, Lesson 3. The Context object is of type System.Web.HttpContext.

"Because ViewState stores data on the page, it is limited to items that can be serialized. If you want to store more complex items in ViewState, you must convert the items to and from a string."

This quote opens up the way toward realizing that much of the ASP.NET state information is ultimately limited to two types, string and object. What is not suggested in this lesson is the possibility of storing state in user-defined static members of the Application object. I will assume that this is an "advanced topic" and that backwards compatibility is more important in this lesson than moving on to new object-oriented designs.

Instead of this "advanced topic," the first code listing of this lesson clearly shows that the Context1 type, extending System.Web.UI.Page, exposes the string type Value that can be accessed by the Context2 type (in the second code listing). It follows that this lesson shows that strongly typed Page-level state information can be passed (as long as it can be represented by strings).

The following quotes highlight the known issues associated with ASP.NET designs based on Application and Session states:

"Application and Session state variables are created on the fly, without variable name or type checking. You should limit your access points to these variables."
"Maintaining Session state affects performance."
"Application state variables are available throughout the current process, but not across processes."
"Application and Session state variables are powerful and therefore scary things."
"If a page does not require state information at the session level, you can turn this off to achieve better performance."

For more information, see MSDN article "ASP.NET Session State" here:

http://msdn.microsoft.com/library/en-us/dnaspnet/html/asp12282000.asp