One of the more exciting features of ASP.NET is the view state concept. It allows you to save Web Form properties across different server requests. While this simplifies maintaining data on a Web page, it does have disadvantages. This week, I examine view state, as well as enhancements to the feature in ASP.NET 2.0.
Maintaining state
The basic idea behind the view state feature is that when a form is submitted in ASP .NET, the form reappears in the browser window together with all form values. This is easily demonstrated with an example as the C# Web Form in Listing A shows. Listing B offers the equivalent VB.NET code.
It is a basic Web Form that accepts user input in a text field and displays the contents of the field in a label when the button is selected. If you test the form, you'll notice the contents of the text field are maintained between button clicks. In part, this is accomplished with the view state feature, which is a default feature of ASP.NET Web Forms. You will see the view state field if you view the page source when it is opened in a browser as the following demonstrates:
"dDwtMjA1MzM3NDEyNzt0PDtsPGk8Mj47PjtsPHQ8O2w8aTw3Pjs+O2w8dDxwPHA8bDxUZXh0Oz47bDxkZDs
+Pjs+Ozs+Oz4+Oz4+Oz6Tt+UvLyB2DGSLR/NhrjKwZrP7BQ==" />
As you can see, the view state information is not stored as clear text. By default, a machine-specific authentication code is calculated on the data and appended to the view state string. The resulting text is then Base64 encoded but not encrypted.
You can use a higher level of security via the Page class' EnableViewStateMac property. When used, the view state MAC is an encrypted version of the page's view state. When you set the EnableViewStateMac attribute to true, the regular encoded and encrypted view state are compared to verify that it has not been tampered with on the client.
You may choose to disable the view state feature by setting the EnableViewState property of the ASP.NET Page class to false. This may be accomplished in the page control directive like the following line accomplishes:
<%@ Page language="vb" EnableViewState="false" %>
Or, you may choose to enable or disable the feature in code as the VB.NET sample in Listing C demonstrates.
In addition to disabling or enabling the entire page, most data controls such as the TextBox, DataGrid, and Repeater controls provide an EnableViewState property that allows granular control over what is stored in view state.
An interesting aspect of the hidden field is that even if EnableViewState is false, there may be a hidden view state field rendered with the page that is used by ASP.NET to detect postback.
In the simple examples presented so far, using view state is overkill. This is due to the fact that once the page is loaded and populated via the view state, the page proceeds to read information from the Page's Request object and uses those values to override most of the settings for the controls on the page. This doesn't mean view state is unnecessary; it just points out that you should use it with care. Another way to utilize the view state feature is via coding.
Using code
You may programmatically access a page's view state along the same lines as working with a user's session—like working with dictionary object. The StateBag class implements the view state and manages the information that ASP.NET pages and embedded controls persist across successive posts of the same page instance. Listing D adds a Label control to the first example to illustrate storing values in view state. The value stored in the view state object is retrieved during the loading of the page and displayed in the Label control.
A good way to illustrate disabling the view state is by setting the EnableViewState property to false in this example. If set to false, you'll notice the additional Label control is always empty when the code runs. Also, you'll notice the system does not produce an error if view state is used when it has been disabled—it just doesn't work. Also, the contents of values stored in the ViewState object are valid only during the life of its container page.
Use view state with care
Most developers advise not to use the view state feature unless it is absolutely necessary, so turn it off for any control that doesn't need it. The reason is simple: storing large amounts of data in a hidden field requires that field be transferred during server calls and it takes time. If you don't believe it can't get out of control, load up a page with lots of data (with view state enabled) and take a look at its source—the size of that hidden view state field is a bit overwhelming, isn't it?
ASP.NET 2.0
With the release of ASP.NET 2.0, Microsoft recognized the need to overhaul some aspects of the view state feature. This includes the following:
- A change in the serialization format used to store view state data, which results in more efficient data retrieval and parsing via a smaller footprint.
- View state is partitioned into two categories: view state and control state. It addresses the problem of view state being an all or nothing feature for controls in ASP.NET 1.1. Control state is another type of hidden state reserved exclusively for controls to maintain their core behavioral functionality.
Working with it
View state is a key element of the ASP.NET architecture. It allows you to easily persist data between server roundtrips, and it is utilized by the postback architecture. It does consume valuable resources, so you should use it when appropriate.
No comments:
Post a Comment