Asp.net|web first, Introduction to Server Scripting Basics
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 working in a pattern of requesting-> receiving requests-> processing requests-> sending responses, and every interaction with the client raises a new request, so a web The page life cycle 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 actually not complicated, and you can use ASP.net programming friends to go 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:
#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);
}
<summary>
Designer supports required methods-do not use the Code editor to modify
The contents of this method.
</summary>
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 code that uses Vs.net to produce page, we see, there are two methods, one is OnInit, one is InitializeComponent, the latter is called by the former, actually
