When defining a provider within configuration, it is required for the type attribute to be defined. The type value must be a fully qualified name following the format:
type="[namespace.class], [assembly name], Version=[version], Culture=[culture], PublicKeyToken=[public token]"
The strongly typed name is desired, however, it is also legitimate to use the shorter style assembly type name. For example:
To learn more about the Provider Model design pattern, please read Provider Model Design Pattern and Specification, written by Rob Howard.
The model defines a set of classes to support the view state provider framework. The diagram shown below depicts the ViewState Provider Object Model and its interaction with Page.
ViewStateManager- It exposes two static methods,
SaveViewState, which are used by the application (Page, in our context) to load or save its view state, respectively. It contains no business logic; instead it simply forwards these calls to the configured provider, say
SqlViewStateProvider. It is the responsibility of the
SqlViewStateProviderprovider class to contain the implementation of these methods, calling whatever Business Logic Layer (BLL) or Data Access Layer (DAL) to complete the job.
/// <summary> /// Loads any saved view-state of the current page from virtually any /// storage medium other than a hidden field /// </summary> /// <param name="pControl">System.Web.UI.Page</param> /// <returns>The saved view state</returns> public static System.Object LoadPageState(System.Web.UI.Control pControl) /// <summary> /// Saves any view-state information of the page to virtually any /// storage medium other than a hidden field /// </summary> /// <param name="pControl">System.Web.UI.Page</param> /// <param name= "viewState">An System.Object in which /// to store the view-stateinformation</param> public static void SavePageState (System.Web.UI.Control pControl, System.Object viewState)
ProviderBase- is used to mark implementers as a provider, and forces the implementation of a required method and property common to all providers.
ViewStateProviderBase- it exposes a standard interface (well-known APIs) to the view state management service, and all the custom ViewState providers must inherit from this class. The well-known APIs are:
public abstract System.Object LoadPageState(System.Web.UI.Control pControl); public abstract void SavePageState(System.Web.UI.Control pControl, System.Object viewState);
ViewStateConfigurationHandler- it interprets and processes the settings defined in XML tags within the
<viewstate>section in the Web.config file and returns an appropriate configuration object based on the configuration settings.
ViewStateConfiguration- it contains the settings information for all the ViewState providers defined in the Web.config file.
SqlViewStateProvider provider inherits from
ViewStateProviderBase class, it uses SQL Server as the data store to store and retrieve the view state of pages during the page life cycle. The table schema designed for storing the view state is as simple as the diagram shown below:
||An unique key to identify the view state of a particular page|
||The view state of a page.|
||The last visit timestamp of this view state|
Before a page renders its output, the
SavePageState method will be called by the framework to save the page's view state. Internally, it checks if a hidden field (a.k.a.
HtmlInputHidden control) named "
__vsKey" exists in the page's
Controls collection, the hidden field will be created if it doesn't exist. The method's code simply creates an instance of the
LosFormatter object and invokes its
Serialize() method, serializing the passed-in view state information to the
StringWriter writer. Following that, a globally unique identifier (GUID) will be generated and used as the key to save the view state of a particular page to a database table. Last, but not least, this GUID is stored in the hidden field of this page.
When the page posts back,
LoadPageState method will be called by the framework to retrieve the saved view state of a particular page. This is accomplished by using the GUID stored in the "
__vsKey" hidden field on the last visit to lookup the view state in the database table, and returning the deserialized object via the
Derialize() method of
There is one problem here, each time a user visits a different page, a new record holding that page's view state will be created in the database table. Over time, this will lead to millions of records, which may seriously affect the performance of the lookup process. Some sort of automated task would be needed to periodically clean out the view state records older than a certain date. I leave this as an exercise for the reader.
The diagrams below show the differences before and after using the
SqlViewStateProvider provider to store the view state in database instead of storing them in a hidden field named "
__VIEWSTATE " of the page.
View State stored in hidden field (Before)
View State stored in database (After)
This article ships with two view state providers, available from the link at the top of this article. One of the providers store view state into a SQL Server database table, which is described throughout this article, and the other has the capability of compressing the view state. As noted earlier, if the default functionality of these providers do not meet your needs, you can create your own provider and plug it into the framework.
With ViewState Provider Framework in place, developing a custom view state provider is as easy as the few steps listed below:
ViewStateProviderBaseclass. (Remember to follow the naming patterns for provider classes).
<providers>section in the Web.config file.
defaultProviderattribute's value of
<viewstate>section in the web.config file to the newly created provider name.
The provider design pattern allows developers to have a flexible design and a rich, enterprise-level extensibility model. More importantly, you can very easily use one provider for your development tasks, and a different one for the application in production, simply by changing some configuration. Last, but not least, this is an important new design pattern in ASP.NET 2.0, which is extensively used in many common web application features like site membership, role management, personalization, etc. So, start using it in your applications today, and and you'll be ahead of the curve in understanding this design pattern in ASP.NET 2.0 tomorrow.
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
General News Suggestion Question Bug Answer Joke Praise Rant Admin