Viewstate in ASP.NET 2.0

All of us know that ViewState has been really cumbersome in ASP.NET 1.1 for large page sizes and contributing to slow performance.

But in .NET framework 2.0 the ASP.NET 2.0 has some enhancements to state management.

• ASP.NET 2.0 now has control state to ensure few specific properties of a control are retained across postbacks irrespective of whether ViewState is enabled or not.
• By setting a property MaxPageStateFieldLength, you can control how big the ViewState can grow after which it would be separated into multiple chunks.
• We are no longer limited to using SQL Server for database-based session storage mechanism. A custom provider can be created to persist session data to other data stores, such as Oracle.

ASP.NET version 2.0 retains much of the functionality of ASP.NET version 1.1, including automatic page-state persistence using view state, and database support for session and application state. Additionally, ASP.NET 2.0 adds two new features: view-state chunking and control state.

Control State

Sometimes you need to store control-state data in order for a control to work properly. For example, if you have written a custom control that has different tabs that show different information, in order for that control to work as expected, somehow the control needs to know which tab is selected between round trips. The ViewState property can be used for this purpose, but view state can be turned off at a page level by developers, effectively breaking your control. To solve this, the ASP.NET page framework exposes a new feature in ASP.NET version 2.0, called control state.

The ControlState property allows you to persist property information that is specific to a control and cannot be turned off like the ViewState property. To use control state, your control must call the RegisterRequiresControlState method during initialization and then override the SaveControlState and LoadControlState methods.

Custom Session-State Management

By default, session-state values and information are stored in memory within the ASP.NET process. ASP.NET also provides session-state providers that allow you to use a session-state server that keeps session data in a separate process, or you can persist session state data to a SQL database. However, with ASP.NET 2.0, you can create custom session-state providers that allow you to customize how session-state data is stored in your ASP.NET applications. For example, you might consider creating a custom provider for the following reasons:

• You need to store session-state information in a data source other than SQL Server, such as a Visual FoxPro database or an Oracle database.

• You need to manage session-state information using a database schema that is different from the database schema used by the providers that ship with the .NET Framework. An example of this would be shopping cart data that is stored with a predefined schema in an existing a SQL Server database for a company or Web site.