Pandering to persistent page states

ASP.NET 2.0 provides a class for storing information on the server side so it doesn't pass between the client and the server in a hidden HTML field. It's a handy feature, Ed Tittel writes.

One of the nice new features in ASP.NET 2.0 is added support for a different location in which to store ViewState

data for Web pages. In fact, you can create and use a new class to store ViewState information on the server side rather than having to pass it back and forth from client to server in a hidden HTML text field.

Within an ASP.NET control, developers can use ViewState and control state values to maintain state information between page and other resource requests from a client browser. But most methods for capturing and maintaining state information depend on building and passing hidden text fields from client to server inside requests and then passing an updated version of that same information back to the client when the request gets a reply from the server. This is how information remains available, or persistent, from one page view or resource request to the next.

ASP.NET ups the ante by providing two page state persisters to enable developers to maintain state information over time. The HiddenFieldPageState persister maps to the old-fashioned back-and-forth model where state information goes into a hidden text field and bounces back and forth, while the SessionPageStatePersister uses server sessions associated with a specific browser session to store the data on the server side.

This helps keep overhead to a minimum, since large amounts of hidden data no longer need to travel between client and server with each page access. On the other hand, adding session support for persistent data increases server activity and overhead, and consumes more server resources. Nor are hidden fields subject to timeouts the way sessions must be, to prevent them from dragging on forever. But because applications can store persistence data in a database, the load can be shared with other servers, and good timeout choices can prevent overly quick timeouts from disrupting meaningful user activity.

Because the HiddenFieldPageState is the default persister, you must override the PageStatePersister property of a page and return an instance of your persister of choice. Matt Gibbs' article ASP.NET 2.0 Page State Persister not only explains the details of how to use the SessionPageStatePersister, it also provides in-depth views of HTML source code for real Web pages to illustrate how much data volume is reduced when state information stays on the server, and only update information needs to move back and forth instead of an entire state image, as it were.

Those who can handle the increased consumption of resources on the server side, and whose users won't be overly discommoded by occasional timeouts owing to inactivity or communications problems, should definitely dig deeper into this technique. It can be of great value for applications or services where client bandwidth is limited and where sensitive transactions do not (or only seldom) occur.


Ed Tittel is a full-time writer and trainer whose interests include XML and development topics, along with IT Certification and information security topics. E-mail Ed at etittel@techtarget.com with comments, questions, or suggested topics or tools to review.
This was first published in January 2006

Dig deeper on ASP.NET development best practices

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchCloudComputing

SearchSoftwareQuality

SearchSOA

TheServerSide

SearchCloudApplications

Close