Goodbye ViewState!
Problem
From the very beginning of the study of ASP.NET technology I was unpleasantly surprised by two things: the presence (or rather its huge size on complex pages) of the view state (ViewState) as a hidden field on the page and the naming (ID) of the server element containers. After PHP, where every character displayed in the browser is under control, this was a disappointment.
Well, I was more or less reconciled with the naming problem, in the end, styles for elements can be applied using the class (especially since it works faster than by id ), and to use id in client scripts, you can display the ClientID property of the server control .
ViewState needed to be curbed :) Indeed, the presentation state occupying 50% of the page size is not very good from the point of view of client optimization. Plus to increase the size of the page, from the position of SEO, too, on these pages, not all is bright. I can make an assumption, even without being a search engine specialist, that the page with <h1> the right text </ h1> ranks better than <80kb some garbage> <h1> the right text </ h1> (correct me if it's not right ).
')
What can be done?
Dino Esposito in his book “ASP.NET 2.0. The basic course (chap. 13) offers two solutions to the problem: disabling the ViewState of elements for which its absence does not disrupt the operation of the application and transferring the view state to the server.
With the disconnection of ViewState, everything is transparent, but the second method will be discussed in detail.
So, we are offered to create a class derived from Page, redefine two methods in it (save SavePageStateToPersistenceMedium and load LoadPageStateFromPersistenceMedium view state) and implement the method of saving / reading ViewState manually. Then all your pages need to be inherited from this class.
Tell me, who has ever done this? ;)
Surely there should be a simpler way when you don’t need to implement anything yourself and not affect the already written application code. And, turning to my more experienced colleagues, I found this way.
Starting with version 2.0 in ASP.NET, the adapter mechanism has appeared. Using this mechanism, you can change the behavior of controls (and pages too) without affecting their code.
Create an adapter for the page:
namespace Samples.AspNet.CS {
using System.Web.UI;
public class MyPageAdapter : System.Web.UI.Adapters.PageAdapter {
public override PageStatePersister GetStatePersister() {
return new SessionPageStatePersister( Page );
}
}
}
* This source code was highlighted with Source Code Highlighter .This adapter overrides the GetStatePersister method, which returns an object used by the web page to customize controls and view states. The default is HiddenFieldPageStatePersister (storing the ViewState in a hidden field in the browser), changing it to SessionPageStatePersister (storing the ViewState in a session on the server).
Now we need to connect our adapter to the pages.
In the folder App_Browsers create the file default.browser:
< browsers >
< browser refID ="Default" >
< controlAdapters >
< adapter controlType ="System.Web.UI.Page" adapterType ="Samples.AspNet.CS.MyPageAdapter" />
</ controlAdapters >
</ browser >
</ browsers >
* This source code was highlighted with Source Code Highlighter .Using this file, we connect our adapter to all pages inherited from the Page class.
We try!
PS It is advisable to disable ViewState in any case on elements where it is not needed.
Information used:
Source: https://habr.com/ru/post/60170/
All Articles