C# ViewState Management/Storage - Four Locations!

xbadenx

Rate me:

4.30/5 (7 votes)

5 Nov 20075 min read

51.6K

In this article, I discuss the PageStatePersister, and detail ViewState storage in one of four locations: Session, Application, AppGlobals, and server Cache.

Download StaticAppGlobalsAppGlobals.zip - 3.4 KB

Introduction

From an SEO standpoint, page size matters, as well as the location of text on your page. When creating a site with VS .Net, we end up with a ViewState variable, which in some cases, can take up a whole lot of space near the top of the page. This could, in fact, dilute the contents' importance on a given web page. In terms of page size, some search engines only cache the first 120kb of data.

This project was an attempt at finding another location to store the ViewState. In this case, I made four locations available for storage:

Session
Application
AppGlobals
Cache

This can be easily implemented in any C# project by creating a base class, referencing it in all classes, and selecting the storage location in an appSettings key in the Web.config. What is missing, however, is a SQL Server storage location. I'd be quite willing to incorporate at any such implementations!

Before fully diving into the code, I'd like to first discuss why it's important, and how the PageStatePersister, really didn't help.

Background

Enter the importance of reducing the ViewState parameter size. My initial reason for writing this code/putting it together, are a bit different that Oleg Sobol's in this (ViewStateProvider_Net2_0.asp) article, but I think are just as applicable, but our core reason is the same – ViewState size – it does matter.

Unfortunately it's been a while since I wrote this internal article, and haven't fully referenced all the sources. So if I've used some of your code, I apologize in advance.

ASP.Net ViewState Management

<o:p>

I tested using no ViewState management, ASP.Net 2.0's PageStatePersister, and the server caching method.<o:p>

<o:p>

My overall results show that the server caching method is superior to the others. In some cases, the payload of the PageStatePersister is about equal to that of the server cache method, but on pages that contain a higher number of server controls, the PageStatePersister falls dramatically short of the server cache method (see Login.aspx below).<o:p>

<o:p>

Server caching offers four ViewState stores - session, application, appglobals, cache. For testing purposes I only used server caching, as the data below reflects it is the superior method.<o:p>

<o:p>

It is my conclusion, based on this and the benchmark tests located at http://www.eggheadcafe.com/articles/20040613.asp, that we use the server cache method.<o:p>

<o:p>

ViewState test without the server-side scheme is in the first column; the four server side schemes follow:<o:p>

<o:p>	VIEWSTATE WEB STRESS COMPARISON<o:p>				<o:p>
TEST NAME<o:p>	VIEWSTATE<o:p>	SESSION<o:p>	APPLICATION<o:p>	CACHE<o:p>	GLOBALS<o:p>
NUMBER OF HITS<o:p>	3322<o:p>	18483<o:p>	18476<o:p>	20170<o:p>	16723<o:p>
REQUESTS /SEC<o:p>	27.64<o:p>	153.8<o:p>	153.74<o:p>	167.84<o:p>	140.32<o:p>
TOTAL BYTES REC'D (KB)<o:p>	68016.63<o:p>	22923.25<o:p>	22977.13<o:p>	25074.51<o:p>	20798<o:p>
PERCENT DIFFERENCE<o:p>	N/A<o:p>	456.44%<o:p>	456.22%<o:p>	507.24%<o:p>	407.67%<o:p>

<o:p>

Regarding the server stores method, I've used the same design pattern myself – first routing data through a base class – very slick.<o:p>

<o:p>

I've created an assembly containing the ViewState handler, which I can import into any future projects that use these classes. Once again – write once, use anywhere. I also converted some of the code for better usability with 2.0.<o:p>

<o:p>

Test results below:<o:p>

<o:p>

Default01.aspx<o:p>

<o:p>

No Viewstate Management: ~ 329 characters | Payload: 1k<o:p>

<o:p>

PageStatePersister: ~ 129 characters | Payload: < 1k<o:p>

<o:p>

Server Cache Viewstate Storage: ~ 140 characters | Payload: < 1k<o:p>

<o:p>

No Viewstate Management: ~ 349 characters | Payload: ~ 1k<o:p>

<o:p>

PageStatePersister: ~ 149 characters | Payload: < 1k<o:p>

<o:p>

Server Cache Viewstate Storage: ~ 141 characters | Payload: < 1k<o:p>

<o:p>

No Viewstate Management: ~ 1345 characters | Payload: ~ 2k<o:p>

<o:p>

PageStatePersister: ~ 1353 characters | Payload: ~ 2k<o:p>

<o:p>

Server Cache Viewstate Storage: ~ 141 characters | Payload: < 1k <o:p>

Managing the ViewState

The solution is to create a base class to manage the Viewstate.<o:p>

Create an Assembly called StaticAppGlobals where three files will reside:<o:p>

AppGlobal.cs<o:p>
BasePage.cs (this is your base class that will be inherited in all classes)<o:p>
viewStateSvrMgr.cs<o:p>

<o:p>

Setting the ViewState Storage Location

We can select to store the ViewState in one of several locations:<o:p>

Session<o:p>
Application<o:p>
Appglobals<o:p>
Cache<o:p>

<o:p>

Selection of the receptacle is done in the web-app's Web.config file:<o:p>

<appSettings>
    <add key="ServerSideViewState" value="true"/>
    <!--ViewStateStore: session|application|appglobals|cache-->
    <add key="ViewStateStore" value="cache"/>
</appSettings>

Using the Base Class

Since each class needs to inherit System.Web.UI.Page we will inherit this from our base class, and inherit our base class in all classes:<o:p>

Instead of :<o:p>

public partial class Default : System.Web.UI.Page
{
    ... 
}

The definition of our class now becomes:

using StaticAppGlobals;  // viewstate management uses BasePage
public partial class Default : BasePage
{
    ... 
}

Now, since all pages must inherit Page, the base class inherits this:

namespace StaticAppGlobals
{
    public class BasePage : System.Web.UI.Page
    {
        ...
    }
    
    ...
}

... and now, you're off to the races, with C# ViewState management!

Points of Interest

While using the Server Cache method on a heavily-visited site without proper cache management, a server crash can be experienced, so the other methods would be preferable.

I haven't had a chance to work on a SQL implementation, but would love to see one added to this.

I've added this to several projects I've created. One, gave administrators the options to select the storage location from a radio button list. Thus, no re-compiling and the change was instant.

History

None yet...

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

Written By

xbadenx

Systems Engineer

United States

I am a technical architect/senior software engineer, technical trainer, entrepreneur.

I have worked in several sectors from healthcare, to entertainment and global intelligent traffic systems, using .Net, SQL, NoSQL and some of the latest technologies to deliver quality software systems for clients.

Past tech flavors include C#, WCF, SOA, MVC, MVVM, Silverlight, Assembler, Pascal, VB, Java/J2EE/EJB/JDBC, Perl, NLTK, TSQL, NoSQL, KendoUI, NodeJS, SignalR, Backbone JS, Angular JS, Latest .Net technologies, Amazon AWS...

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

C# ViewState Management/Storage - Four Locations!

Introduction

Background

ASP.Net ViewState Management

Managing the ViewState

Setting the ViewState Storage Location

Using the Base Class

Points of Interest

History

License

Comments and Discussions