Storage Location Optimization-save view status information on the server rather than the client

Storage Location Optimization-save view status information on the server rather than the client

 

This article is excerpted from the book Ding Jie Niu: vertically cutting ASP. NET 3.5 controls and component development technology

By default, view status information is stored on the client and does not occupy server resources. (This indicates that server resources are continuously occupied for a certain period of time. The view status is only displayed on the page, the service correctly parses the view status content to occupy the server memory for a while. After the page is displayed, the view is stored in the hidden control domain on the page ). When the page structure is complex, a large number of bytes of view information may occur, resulting in a bandwidth bottleneck. To solve this problem, we can choose to store view information on the server, database, or file storage media. In this section, we will save the view status to the server session as an example to illustrate its implementation method.
Create a new page sessionpagestatepersister. aspx: the content on the page still uses the test page content of the previous control status control. After the page content is set, rewrite the pagestatepersister attribute of the base class page in the background code, as shown below:
/// <Summary>
/// For more information about this book, see:
// Http://blog.csdn.net/ChengKing/archive/2008/08/18/2792440.aspx
/// </Summary>
Public partial class page_sessionpagestatepersister: system. Web. UI. Page
{
Protected override pagestatepersister
{
Get
{
Return new sessionpagestatepersister (this );
}
}
}
To make it easier to understand, the following is the default system implementation source code of this attribute on page:
Protected virtual pagestatepersister
{
Get
{
If (this. _ persister = NULL)
{
Pageadapter = This. pageadapter;
If (pageadapter! = NULL)
{
This. _ persister = pageadapter. getstatepersister ();
}
If (this. _ persister = NULL)
{
This. _ persister = new hiddenfieldpagestatepersister (this );
}
}
Return this. _ persister;
}
}
The default persistence mechanism of ASP. NET is to store the view State on the client using the hiddenfieldpagestatepersister class, that is, the system returns the hiddenfieldpagestatepersister class instance in the property pagestatepersister, indicating that it is stored in. We overwrite this attribute above and return the sessionpagestatepersister class instance. The sessionpagestatepersister class indicates storing the ASP. NET page view status in the web server session.
OK. Run the page and check its hidden Domain View information. The _ viewstate is changed from the original:
<Input type = "hidden" name = "_ viewstate" id = "_ viewstate" value = "/comment + response + ica8yni + response/response + ica8yni + response /kv53lrzjkuobmj1_ku7bnirbmgiesioeep + + 8 joaikeeahominoijsuwwseayr + S/Hangzhou + logs/1gisxczc2fhdmltqy1x "/>
Now:
<Input type = "hidden" name = "_ viewstate" id = "_ viewstate" value = "/comment"/>
In addition, both hiddenfieldpagestatepersister and sessionpagestatepersister inherit the base class system. web. UI. pagestatepersister: this base class allows a custom persistence mechanism. If you do not want to store data in a hidden domain on the client or in a session, you can define a derived class of this class to implement a custom persistence mechanism. In section 6.8.2, an example of deriving the system. Web. UI. pagestatepersister class is provided.
In addition to rewriting the pagestatepersister attribute of the base-class page to implement the specified persistence class object, you can also implement the same function by implementing the page handler of the system. Web. UI. adapters. pageadapter class. The pageadapter class is an abstract class. You can modify a webpage to adapt to a specific browser and provide a base class that can be directly or indirectly inherited by all page adapters. The following is an example of a custom page adapter:
/// <Summary>
/// For more information about this book, see:
// Http://blog.csdn.net/ChengKing/archive/2008/08/18/2792440.aspx
/// </Summary>
Public class sessionpageadapter: system. Web. UI. adapters. pageadapter
{
Public override pagestatepersister getstatepersister ()
{
Return new sessionpagestatepersister (this. Page );
}
}
Then add the app_browsers directory under the site and add a file named sessionpageadapter. browser with the following content:
<Browsers>
//... ...
<Browser refID = "default">
<Controladapters>
<Adapter controltype = "system. Web. UI. Page" adaptertype = "kingcontrols. sessionpageadapter"/>
</Controladapters>
</Browser>
</Browsers>
Run the page and you will find the same effect as before. Both methods can store view information in the server session. The difference is that this method affects all the pages under the entire site.
Sessions are generally used to store short-term information specific to individual sessions, which is much safer than storing the information in the hidden domain of the client. However, this method occupies the server memory, so do not store a large amount of information in sessions when there are many clients.