asp.net Web page Application in-depth discussion 1th/2 page _ Practical Tips

Introduction to the Basics of server scripting
First, let's review the basics of how Web Server Pages are executed:
1, the client through the browser's address bar typing address to send the request to the server side
2, the server received the request, sent to the corresponding server-side page (that is, script) to execute, the script produces the client's response, sent back to the client
3. The client browser receives the response from the server, parses the HTML and renders the graphical page in front of the user
For server and client interaction, there are usually several main ways to do this:
1, form: This is the most important way, standardized control to get user input, form submission to send data to server-side processing
2, QueryString: By the URL after the parameter to reach the parameters to the server, this way in fact, and get the form is the same
3, Cookies: This is a more special way, usually used for the identification of users
Second, ASP. NET Introduction
The traditional server scripting language, such as ASP, JSP, and so on, the way to write server script, are embedded in the HTML interpretation or compile the execution of code, the server platform to execute the code to generate HTML; For this similar script, the life cycle of the page is actually very simple, from the beginning to the end, By executing all the code, of course, a servlet written in Java can write more complex code, but structurally, it's no different from JSP.
Asp. NET, broke the tradition; ASP.net adopted the codebehind technology and server-side control, added the concept of server-side events, changed the script language writing mode, more close to window programming, so that the Web programming more simple, intuitive; but we want to see that ASP . Net itself does not change the basic pattern of WEB programming, but encapsulates some details, provides some Easy-to-use functionality, makes code easier to write and maintain, and, to some extent, complicates the way the server side executes, which is what we're going to talk about today: asp.net Web The life cycle of the page.
third, ASP. NET Request processing mode
We say, ASP. NET Web page does not break out of the Web programming model, so it is still in the process of requesting the-> to receive requests-> processing requests-> sending responses, and each interaction with the client raises a new request, so a Web page's lifecycle is based on a single request.
When IIS receives a request from the client, the request is handed over to the aspnet_wp process, which looks at whether the requested application domain exists, creates one if it does not exist, and then creates an HTTP runtime (HttpRuntime) to process the request, the runtime " Provides a set of ASP.net runtime services for the current application (excerpted from MSDN).
HttpRuntime maintains a series of application instances while processing the request, That is, an instance of the application's global Class (global.asax), which, when not requested, is stored in an application pool (in fact, the application pool is maintained by another class, httpruntime is simply called), and each time a request is received, HttpRuntime acquires a Idle instances to process requests that do not process other requests until the end of the request, and then return to the pool after processing, "an instance is used to process multiple requests during its lifetime, but it can process only one request at a time." "(excerpted from MSDN)
When an application instance processes a request, it creates an instance of the request page class and executes its ProcessRequest method to handle the request, which is the beginning of the Web page life cycle.
four, aspx page and Codebehind
Before delving into the life cycle of a page, let's look at some of the relationships between ASPX and Codebehind.
<%@ Page language= "C #" codebehind= "WebForm.aspx.cs" inherits= "Mynamespace.webform"%>
Believe that the use of codebehind technology friends, the top of the ASPX sentence should be very familiar with, we come to an analysis of it:
Page language= "C #" This is not much to say
codebehind= "WebForm.aspx.cs" means a code file that is bound
Inherits= "Mynamespace.webform" is very important, it represents the class name that the page inherits, that is, the class in the Codebehind code file, this class must derive from the System.Web.WebControls.Page
From the above we can analyze, in fact, the class in Codebehind is a page (ASPX) base class, here, may be some friends to ask, in writing ASPX, completely in the form of ASP, in HTML code or embedded in the server control, did not see the so-called "class" Shadow, huh?
This question is not really complicated, and you can use ASP.net programming friends to your system disk: \windows\microsoft.net\framework\< version number >\temporary asp.net files directory, Here's a temporary file of all the ASP.net applications that exist on this computer. The name of the subdirectory is the name of the application, and then it goes down two tiers (to ensure uniqueness, ASP.net automatically generates a two-tier subdirectory, and the subdirectory name is random), and then we find that there are many similar: " Yfy1gjhc.dll "," Xeunj5u3.dll "and" Komee-bp.0.cs "," 9falckav.0.cs ", such as the source files, In fact, this is the result of aspx being asp.net dynamically compiled, and we can find that by opening these source files:

public class WebForm_aspx:MyNamespace.WebForm, System.Web.SessionState.IRequiresSessionState

This confirms what we said earlier, ASPX is a subclass of the code-bound class whose name is the ASPX filename plus the "_aspx" suffix, and by studying the code we can find that virtually all of the server controls defined in ASPX are generated in these codes, and then dynamically generate the code, Write the code that was originally embedded in ASPX in the appropriate location.
When a page is accessed for the first time, the HTTP runtime uses a code generator to parse the ASPX file and generate the source code and compile it, then call the compiled DLL directly later, which is why ASPX was very slow on its first visit.
To explain the problem, let's look at another question. When we use code binding, we drag a control on the design page and switch to Code view, we can use the control directly in the Page_Load, since the control is generated in the subclass, why is it possible to use it directly in the parent class?
In fact, we can see that every time you drag a control onto a page with Vs.net, the code-bound file always adds a declaration like this:

protected System.Web.WebControls.Button Button1;

We can see that this field is declared as protected and the name is consistent with the ID of the control in ASPX, and the problem is solved by thinking it over. We mentioned earlier that the source code for ASPX was generated and compiled dynamically by the generator, which generates code that dynamically generates each server control, and when generated, it checks that the parent class has declared the control, and if it does, it adds a code similar to the following:

This. DATAGRID1 = __ctrl;

This __ctrl is the variable that generates the control, and it assigns the reference of the control to the corresponding variable in the parent class, which is why the declaration in the parent class must be protected (and can actually be public), because the subclass is guaranteed to be callable.
Then when executing the Page_Load, because the declaration of the parent class is already assigned a value in the initialization code in the quilt class, so we can use this field to access the corresponding control, we will not commit to use the control in the constructor in the code binding file, causing the exception of the null reference error, Because the constructor is executed first, the initialization of the subclass has not yet begun, so the field in the parent class is NULL, and when the subclass is initialized we put it behind the discussion.
Five, page life cycle
Now back to the third title, we talked about the instance of HttpApplication receiving the request and creating an instance of the page class, which is actually an instance of the dynamically compiled ASPX class, which we learned in the previous header that ASPX is actually a subclass of the class in code binding. So it inherits all the protected methods.
Now let's take a look at the code for the Codebehind class that vs.net automatically generates to begin our discussion of the page life cycle:

Copy Code code as follows:

#region Web Form Designer generated code
Override protected void OnInit (EventArgs e)
{
//
CodeGen: This call is required for the ASP.net Web forms Designer.
//
InitializeComponent ();
Base. OnInit (e);
}

Designer supports required methods-do not use the Code editor to modify
The contents of this method.

private void InitializeComponent ()
{
This. Datagrid1.itemdatabound + = new System.Web.UI.WebControls.DataGridItemEventHandler (this. Datagrid1_itemdatabound);
This. Load + = new System.EventHandler (this. Page_Load);
}
#endregion

This is the use of Vs.net generated page code, we see that there are two methods, one is OnInit, one is InitializeComponent, the latter is called by the former, actually this is the beginning of page initialization, in InitializeComponent we see the control 's event declaration and page's load declaration.
The following is a description of the excerpt from MSDN and a sequential table of page lifecycle methods and event triggers:
"Each time a ASP.net page is requested, the server loads a asp.net page and unloads the page when the request completes." The page and the server controls it contains are responsible for executing the request and rendering the HTML to the client. Although the communication between the client and the server is stateless and intermittent, the customer must feel that this is a sequential process. ”
"This illusion of continuity is implemented by ASP.net page frames, pages, and their controls." After a postback, the behavior of the control must appear to start where the last Web request ended. Although the ASP.net page framework makes execution state management relatively easy, control developers must know the order in which controls are executed in order to achieve continuity. Control developers need to understand what information the control can use at various stages of the control lifecycle, what data to keep, and in what state the control renders. For example, a control cannot call its parent until the control tree on the page is populated. The following table provides a high-level overview of the stages in the control lifecycle. For more information, click on the link in the table. ”
The method or event to override for the action that the stage control needs to perform
Initializes the settings that are required to initialize the incoming WEB request life cycle. See Handling inherited events. Init Event (OnInit method)
Load view state at the end of this phase, the ViewState property of the control is automatically populated, as described in maintaining the status in the control. Control can override the default implementation of the LoadViewState method to customize the state restore. LoadViewState method
Processes postback data processing incoming forms, and updates properties accordingly. See Processing postback data.
Note Only controls that process postback data participate in this phase. LoadPostData method (if IPostBackDataHandler is implemented)
Loads the operations that are common to all requests, such as setting up a database query. At this point, the server control in the tree has been created and initialized, the state has been restored, and the form control reflects the client's data. See Handling inherited events. Load Event
(OnLoad method)
Sending a postback change notification raises a change event in response to a state change between the current and previous postbacks. See Processing postback data.
Note Only controls that raise postback change events are involved in this phase. RaisePostDataChangedEvent method
(if IPostBackDataHandler is implemented)
Handles the client-side events that caused the postback and raises the appropriate event on the server for the postback event processing. See catching postback events.

Current 1/2 page 12 Next read the full text