ASP.NET View State is a very powerful feature of ASP.NET that provides a client side state management mechanism. It helps preserve page and control values between complete round trips for client requests. This gives a state full programming capability over a stateless protocol such as HTTP.
ASP.NET View State is stored in a hidden field on the page as an encoded Base64 string, as part of every response sent to the client and is also returned to the server by the client as part of a post back.
<input id="__VIEWSTATE" type="hidden" name="__VIEWSTATE" value="/wEPDwUJNzg0MDMxMDA1D2QWAmYPZBYCZg9kFgQCAQ9kFgICBQ9kFgJmD2QWAgIBDxYCHhNQcm2aW91c0NvbnRyb2xNb2RlCymIAU1pY3Jvc29mdC5TaGFyZVBvaW50LldlYkNvbnRyb2xzLlNQQ29udHJbE1vZDA1XzRlMjJfODM3Y19kOWQ1ZTc2YmY1M2IPD2…==" />
ASP.NET View State does come with a few issues that you need to understand and resolve. Once you resolve these issues, you are able to benefit from ASP.NET View State without any problems. They are discussed below.1. ASP.NET View State is often heavy
First of all, in many situations, ASP.NET View State becomes very large especially when your ASP.NET application has a lot of rich and heavy controls and widgets on its pages. This results in a lot of data traveling back and forth between your browser and the web server.
Due to this heavy payload, your ASP.NET performance drops because your pages are taking longer to respond. This is probably the most visible change you see in your ASP.NET application.
Another impact is the extra bandwidth consumption. This has a financial cost associated with it because you're paying for the bandwidth and if an average ASP.NET View State ends up in 100's of kilobytes, this could easily consume a lot of bandwidth when millions of requests are processed.2. ASP.NET View State is a security risk
ASP.NET View State can also pose a security risk when sending confidential data as part of view state to client. This data is vulnerable to attacks and can be tempered by an attacker which is a serious security threat. You can encrypt the ASP.NET View State data but this is again going to have a performance cost to it.
One way you can resolve ASP.NET View State issues is by storing the actual ASP.NET View State on the Web server and sending a unique token (or ID) in place of it to the browser so the browser can send this token back to the web server next time. The web server then uses this token to find the right ASP.NET View State in its store.
You can do this because the ASP.NET View State encoded string is never used by the browser and is always returned to the web server. So, whether it is an encoded string or a token is the same for the browser. Below is an example of a token being used in place of ASP.NET View State.
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="vs:cf8c8d3927ad4c1a84da7f891bb89185" />
But, if your ASP.NET application is running in a load balanced web farm, the next HTTP request might come to another web server. Therefore, you must store the ASP.NET View State in a shared store that is accessible from all the web servers.
The best place to store ASP.NET View State on the server is in a distributed cache. This way, not only can you have a common store for all web servers, but you also have an extremely fast and scalable in-memory store as compared to SQL Server database or other storage options.
NCache is an extremely fast and scalable distributed cache for .NET. It also lets you store ASP.NET View State to solve the issues described above.
Create an app.browser file in App_browsers directory. Plug in page adapters in the app.browser file as follows:
<browser refID="Default"> <controlAdapters> <adapter controlType="System.Web.UI.Page"adapterType="Alachisoft.NCache.Adapters.PageAdapter" /> </controlAdapters> </browser>
Add the following assembly reference in compilation section of web.config file.
<compilation defaultLanguage="c#" debug="true" targetFramework="4.0"> <assemblies> <add assembly="Alachisoft.NCache.Adapters, Version=22.214.171.124, Culture=neutral, PublicKeyToken=CFF5926ED6A53769"/> </assemblies> </compilation>
Register NCache config section in your web.config file.
<configSections> <sectionGroup name="ncContentOptimization"> <section name="settings" type="Alachisoft.NCache.ContentOptimization.Configurations.ContentSettings" allowLocation="true" allowDefinition="Everywhere"/> </sectionGroup> </configSections>
Specify settings for your config section in web.config file (that was registered above). These settings control NCache ASP.NET View State Caching features.
<ncContentOptimization> <settings viewstateThreshold="12" enableViewstateCaching="true" enableTrace="false" groupedViewStateWithSessions="false"> <cacheSettings cacheName="myCache" maxViewStatesPerSession="3"> <expirationtype="Absolute" duration="1" /> </cacheSettings> </settings> </ncContentOptimization>
In the end, register the HTTP handler in the HttpHandlers section of web.config as following:
<httphandlers> <add verb="GET,HEAD" path="NCResource.axd" validate="false" type="Alachisoft.NCache.Adapters.ContentOptimization.ResourceHandler, Alachisoft.NCache.Adapters, Version=126.96.36.199, Culture=neutral, PublicKeyToken=cff5926ed6a53769"/> </httphandlers>
You gain the following benefits by caching your ASP.NET View State in NCache.
NCache provides you a rich set of features for caching and managing ASP.NET View State. Below is a list of them.
As you have seen, NCache allows you to cache ASP.NET View State on the server in order to optimize your ASP.NET performance. Additionally, NCache provides you a rich set of features on managing your ASP.NET View State more efficiently in the cache. This allows you to develop complex applications and use these features to handle a variety of scenarios.