Turn the devil into an angel, and move ViewState to SqlServer

(Post-writing: Let's clarify the premise. This article is only applicable to ViewState when ViewState is used as a last resort.) ViewState has been controversial for a long time, mainly because of its bloated size, this results in a large amount of data in the customer's response (PostBack), with very little real useful data, wasted bandwidth, and poor user experience. Recent

(Post-writing: Let's clarify the premise. This article is only applicable to ViewState when ViewState is used as a last resort.) ViewState has been controversial for a long time, mainly because of its bloated size, this results in a large amount of data in the customer's response (PostBack), with very little real useful data, wasted bandwidth, and poor user experience. Recent

(Post-posting: I 'd like to clarify the premise. This article is only applicable when ViewState is used as a last resort)
ViewState has been controversial for a long time, mainly because of its bloated size, which leads to a large amount of data in the customer's response (PostBack), but there are very few really useful data, and network bandwidth is wasted, the user experience is also poor.

Recently, Telerik RadGrid is used in the project. After the server is used to bind data to the page, the ViewState size on the page is too large, which seriously reduces the performance. Then, we start to look for an optimization method and try to make the ViewState available.ServerServer Side.

Since the project has been developed to the middle stage, it is impossible to make large-scale changes such as canceling ViewState or using client binding.

To minimize the number of changes, you must not affect the use of the original ViewState. You can only override the LoadPageStateFromPersistenceMedium () and SavePageStateToPersistenceMedium (object state) Methods of the Page class, in the two Override methods, the data is stored somewhere else.

This is the problem. ViewState is only a page cycle. A new ViewState is generated every time a page is opened, and refresh is no exception. If a file or database exists, it's not a joke to accumulate the data, and it cannot be used anymore. Isn't it necessary to write the expired deletion method? It is too troublesome. At this time, the Session will play a major role. The lifecycle of the Session is longer than the ViewState, and will be automatically deleted after expiration. It still exists on the server side and will not increase the data transmission volume. It seems appropriate.

The Code is as follows:

Code
Public class AmoPage: System. Web. UI. Page
{
# Region = Move View State To Session =

Private string _ pageGuid = null;
Public string PageGUID
{
Get
{
If (_ pageGuid = null)
_ PageGuid = this. Request. Form ["_ AmoViewState"];
If (_ pageGuid = null)
_ PageGuid = Guid. NewGuid (). ToString ();
Return _ pageGuid;
}
Set {_ pageGuid = value ;}
}

Protected override object LoadPageStateFromPersistenceMedium ()
{
Return Session [this. PageGUID];
}

Protected override void SavePageStateToPersistenceMedium (object state)
{
RegisterHiddenField ("_ AmoViewState", this. PageGUID );
Session [this. PageGUID] = state;
}

# Endregion
}

However, a problem cannot be ignored. The Session is managed by WebServer by default. It is generally only used to store the user login information in the Session, which is a small amount of data. If you directly plug in ViewState, all of them are stored in the memory. Without a doubt, the WebServer will crash due to the large amount of Session data. It seems that we still need to transfer the Session.

ASP. NET supports custom session management:

Start-> All Programs-> Microsoft Visual Studio 2008-> Visual Studio Tools-> Visual Studio 2008 Command Prompt

Enter the VS command line mode.

Execute aspnet_regsql-S (192.168.19.250)-U sa-P 123-ssadd

This refers to using the username sa password 123 to log on to the SQLServer server 192.168.19.250 and add a database related to status management. In fact, it creates a database ASPState with only an exit stored procedure, and adds two tables in the system database tempdb for storing the Application and Session respectively.

At this time, we have created a database related to status management, and then we only need to make the following settings in Web. config.

At this time, the Session data of the Web application will be stored in the database.

In use, you only need to inherit the original pages from the AmoPage class.

As for the effect, you will know after trying it!
Before use: (familiar with it ...)


After use: (clean, clear, no problem !)