9CBS - Document Center - .NET Title Removes ASP: Database (2) Tommax Keyword .NET, ASP.NET, DATAGRID, ViewState
Third, remove the useless data of DataGrid in ViewState
Finally, I said that I said how to remove useless data in ViewState and reserve useful data. The article writes here, we can see it clearly, DataGrid saves data into two parts, part of the save claim, is the data used by DataKeys and DataItems, we call it Index data. There is also part of the content of data source in DataGrid, which we call list data.
If we remove the list data that is actually useless from ViewState, we greatly reduce the data size of page viewState. When using DataGrid, the root cause of the VIEWSTATE data is that the list data is stored in ViewState.
I didn't find anything in Microsoft .NET Framework SDK document, that is, Microsoft did not give any call sequence and internal working mechanism for DataGrid runtime. No way, I use a tool to get the internal workflow of DataGrid, find that when it is initialized in the data binding, generates a control object called DataGridTable, this object is inherited System.Web.ui.WebControls.Table control . And this object is the first to add (using the controls.add () method) DataGrid. And the DataGrid list data in ViewState is also in the DataGrid. In fact, the data in the cell's cell in ViewState is actually the SaveViewState () method of System.Web.ui.WebControls.Table control. These data are not needed in many cases.
Ok, the reason is found, the problem is good, because Microsoft has given a method of controlling the child control of DataGrid. Since we know that the DataGridTable control is the most synamed control in DataGrid, then we can directly get a reference to the child control in DataGrid through the dataGrid.controls property, and can control the child control after obtaining the reference. The solution is to set the EnableViewState property of the DataGridTable control in the data binding of the data binding.
code show as below:
First, you must rewrite the DataGrid.ItemDatabase, and we use them to control the action of DataGrid before writing HTML to the client. These two events optionally achieve the effect. We use the itemDatabase event to write an example, the DataGrid sample ID is myDataGrid.
[C #]
First join the event in the initializationComponent () method in the page initialization:
Private vidinitiRizeComponent ()
{
this.myDataGrid.ItemDatabase =
New DataGriditeMeventHandler (this.myDataGrid_itemdatabase;
}
Then add control code within myDataGrid_itemdatabase:
Private void myDataGrid_itemdatabase (Object Sender, DataGriditeMeventArgs E) {
MyDataGrid.controls [0] .enableviewState = false;
}
[Vb.net]
Private sub MyDataGrid_itemdatabase (Sender As Object, e as datagriditemeventargs) _
Handles myDataGrid.ItemDatabase
MyDataGrid.contols.Item (0) .NableViewState = false
End Sub
Ok, when using DataGrid, add the above code to reduce 90% of the data of ViewState when using DataGrid. Moreover, many of the DataGrid's functionality is very small, isn't it two full beauty?
note:
1. When the magazo said above is a case, it is necessary to use the DataGrid.pageIndexchangeTargs when using the DataGrid's internal page function. When you call DataGridPageChangeDeventArgs, you must open all viewState, including list data, close any ViewState, They will cause the index of DataGridPageChangeDeventArgs to be lost, and they cannot be paid.
However, this shortcomings are well resolved, many people have written custom paging controls, which do not require DataGrid any data. Very perfect paging features can be provided.
2. (Important) I have conducted a detailed test of the above-mentioned approach, and found that the above approach is really effective, which can greatly reduce the data volume of the viewstate of the ASPX page, but this approach has a note. The place where data cannot be displayed will occur.
I have been strange, Microsoft Write DataGrid why you want to join a DataGridTable class, but also store all database data in ViewState. I found out that I have found that there is a reason for system.web.ui.page.ispostback attribute. We often like to use the page.ispostback property to detect the page for the first time, as follows:
Private Void Page_Load (Object Sender, System.EventArgs E)
{
IF (! page.ispostback)
{
// Page first run, execute data binding
SqlConnection conn = new sqlconnection ("...");
SQLCommand Comm = New Sqlcommand ("...", CONN);
...
...
MyDataGrid.DATABIND () // Data Binding
}
}
Of course, the web page is performed for the first time, the content of the DataGrid is normally displayed, and after using the above removal viewState method, if the page is processed, the content of the DataGrid will disappear. I realized that DataGrid DataGridTable puts the data in the ViewState. Microsoft's design is very rigorous, and their intention is to use the page.ispostback property, only access to a database, you can keep DataGrid data (without left this page), the location of the data is the viewState of the page. in. After the page returns, DataGrid can regenerate the display of DataGrid from ViewState without accessing the database. So Microsoft to sacrifice the speed of the customer to ensure the resources of the server, everyone knows that frequent access to the database is very powerful for the server. So, the method of using it to reduce DataGrid's viewState data is feasible, but must make all pages return processing must be binded, otherwise the DataGrid cannot obtain the database content, and it is impossible to get the data saved in ViewState. After DataGrid will not display anything.
Summary, using the above reduction viewState approach can greatly speed up the client's download display speed, but frequent database access will increase the pressure of the server; use ViewState to reduce the server's pressure, but increase the client download time, they are mutual contradictory. So developers should choose whether to use DataGrid.Controls [0] .NableViewState = false according to the actual situation, how to choose, please think yourself.
