Asp. Research on IsPostBack attribute in net

The IsPostBack property of the page allows you to check whether the. aspx page is a page that is passed back to the server, and in the Page_Load event, the user can check whether the page is passed back to the page before the page is loaded and the control's change property is processed.

It is generally checked in Page_Load whether it is the first time to load this page or whether it is a user submission (PostBack)
if (! IsPostBack) {
Do something
}
Without noticing this problem when accessing and updating the database with the DataGrid, there are a variety of strange problems, such as mine.

Problem Description:
Accessing and updating databases with the DataGrid (SQL Server--northwind--table name:categories--query:select categoryid,categoryname,description Form categories), in addition to the update operation, other functions OK. Do the following for the DataGrid: Click "Edit", the corresponding row data becomes editable, and the edit button is replaced by "Update" and "Cancel". Edit the data, such as to change the AAA in description to BBB. Click the Update button again. The intention is to use this method to replace the modified data (BBB) in the database of AAA, of course, with the Update method. However, after the "update", the data has not changed, I have done the test, the Update method is valid, that is, the Update method is not updated with the new data, but not the old data before the modification, causing the data is not updated (actually updated). Note that my Page_Load event is as follows
private void Page_Load (object sender, System.EventArgs e)
{
Place user code here to initialize page
Olead.fill (DS);//olead--oledbadapter
Dg. DataBind ();//dg--datagrid
}

Analyze the problem (personal conjecture, please correct me):
Since there is no ispostback to determine whether this page is loaded for the first time, the DG (DataGrid) will be data-bound in any case whenever there is a postback. So after any sumbit, DG will go to the database to bind the data without regard to the data on the page.
When the selected data is modified, at the point of "Update", submit this page modified data, and immediately encountered Page_Load event, not to modify data processing, the server on the original page (MS in this way to improve speed?) ), found DG. DataBind (), execute, and then abandon the database update, so that the update results are not seen.

Solve the problem:
The solution is very simple, the Page_Load incident with the IsPostBack judgment on it.
private void Page_Load (object sender, System.EventArgs e)
{
Place user code here to initialize page
Olead.fill (DS);//olead--oledbadapter
if (! IsPostBack)
{
Dg. DataBind ();//dg--datagrid
}
}

Now from the execution order of the ASP. NET page, experience the characteristics of the B/s structure of the program, is the execution sequence description of the asp:

Page_Init (Event raised by page initialization)-->page_load (the event that is raised when the page is loaded)-->control event (events raised by the server control)-->page_ UnLoad (the event that is raised when the page is unloaded from memory)

Page_Init and Page_Unload are not used, but here are some explanations. The difference between the Page_Init and Page_Load events is that only the latter can fully load the control, bind the data, although you can access the control in Page_Init, but its viewstate will not be loaded, so the control only has the default value at this time.
Here's the ViewState, let's start with a general understanding-in fact, there are two viewstate in ASP. One is the control itself, used to maintain the control of some of its own state, such as a color of the function of a space, its viewstate to maintain this function, the ViewState is not accessible to users. Believe that you have written a control of friends will have this feeling, their own write control of course also use one of their own viewstate to maintain the state of the control, while the other viewstate is user, this viewstate and session almost identical, It must be defined before it can be used.

Whenever you click a control such as button, LinkButton, or ImageButton on an ASP. NET Web page, the form is sent to the server. If the AutoPostBack property of some controls is set to true, then when the control's state is changed, the form is sent back to the server.? (AutoPostBack property, which has only two bool values, True/false. If this property is set to False, then the change will not be passed on to the server immediately after the click, and there will be no SelectedIndexChanged event for the control. ）
Each time the form is sent back to the server, it is reloaded, the Page_Load event is started, and all the code in the Page_Load event handler is executed (note that it is executed every time!). ）。
Obviously putting the initialization code of the Web page here is the most appropriate. We often want to execute some code each time the page is loaded, such as data binding for some controls.
When we want to execute some other code (basically the default binding of the data) when the page is first loaded, we even want some code to execute at each load except for the first load. Then we can use the IsPostBack feature to do this. The value of this property is false when the page is loaded for the first time. If the page is reloaded due to loopback, the value of the IsPostBack property is set to true.

In an ASP. NET application, if you need to perform some initialization operations on the first display of the page, you must determine the IsPostBack property!

With ASP. Page.IsPostBack, you can avoid extra work on a round trip: If you handle a server control postback, you typically need to execute the code the first time the page is requested, unlike code that is used for round trips when the event is fired. What if it's checked? Page.IsPostBack property, the code can be conditionally executed, depending on whether there is an initial request for the page or a response to a server control event. This may seem obvious, but you can actually ignore this check without changing the behavior of the page. The quality of this attribute is directly related to whether your program runs in accordance with your initial intent, and also affects the efficiency of the entire page. Because, if the control is bound to the data every time, whether you are the first time to access, or submit data after, then the efficiency of this page program can be imagined.

A b/s structure of the page every time it commits, it will be re-executed from beginning to end.　and C/S structure of the program will not be this, and C/s structure of the program the biggest difference!? In fact, there is no data for the control, because of this reason.