ASP. NET request principle and page life cycle

The day before yesterday to interview, let me say the life cycle, has been known before, but did not speak, was deeply despised; today I got a morning, now send this share, what error please Daniel pointed out ~ ~

Yesterday the interview, again encountered this problem ... Then said a long time, people asked me a user control of the cycle where the implementation, I thought for a long time, also did not want to come out, back had to study again.

Requested this page page-load-> user-defined controls page-load-> this page before rendering page-prerender such a sequence

Page Send Request principle

The browser sends the request encapsulated into the HTTP request message to the server; Server-side HTTP. sys Kernel driver module to receive, this module listens to 80
Port. It first goes to access the registry to determine who is going to handle the request.
The request was handed over to IIS IIS, which was divided into two blocks
1. W3SVC service. It is hosted in the Svchost.exe process. is primarily responsible for distributing requests to specific extensions. Who is it to be distributed specifically?

2. The configuration is within the Inetinfo process. This is the core process of IIS, where IIS metadata is placed.
Here. Access the IIS core process to analyze whether the request for the current suffix is static or dynamic. which extension to handle (. aspx;. ASHX dynamic handing over to aspnet_isapi.dll processing). If the static is returned directly to HTTP. SYS in the browser display, if it is dynamic, to a aspnet_isapi.dll this extension processing in IIS5, is aspnet_wp.exe; In IIS6 and 7, it's w3wp.exe.

Each site runs in a separate work process, and the site is isolated through the process. (Different websites run in different processes, this is called Application pool technology)
In IIS5, however, there is only one process that isolates the association between each process through the application domain;

If it's a dynamic page. The W3SVC service then gives the request to the aspnet_isapi.dll extension. This extension is responsible for starting the ASPNET runtime, which is responsible for creating the ASPNET runtime environment. Also responsible for handing the request to Isapiruntime's PR method, which is the portal for unmanaged and managed programs

In Isapiruntime, this can be seen after the source code
1.ISAPIRuntime object It calls one of its. ProcessRequest (ECB) method; The ECB is a handle to the operating system that points to the current requested memory space, which can be used to get the current request's message, and a Httpworkrequest object is created through the ECB handle. This object is a simple encapsulation of the HTTP request message. That is, the requested header, Newspaper style only;
Once again, distribute the request to the following
Distributed to the HttpRuntime object, the Rrocessrequest (WR) method is called, and the Workrequest object created by the ECB handle is passed in. Encapsulates a HttpContext (request context) based on this object
HttpContext includes HttpRequest (encapsulating HTTP requests), and one is HttpResponse (HTTP-encapsulated response)

And httpruntime also gets a Httpaplication object based on the HttpApplicationFactory plant.
In this factory, when you get an instance, go to the applition pool to see if there are any idle HttpApplication objects. If there is a direct return, if not then compile the global file first to generate a httpappliction derived class, A httpappliction type instance is then created and returned based on this derived class reflection.

This Httpaplication object, called ProcessRequest (HttpContext context), executes 19 pipeline events, and the flow is HttpContext contextual context which takes 23 steps.
In the 8th event, according to the requested address, create a generic handler or an ASPX page type, and turn it into an IHttpHandler interface object;
In the 9th event, the browser sends the SessionID, and based on this value to the server's session pool to find the corresponding Session object, first attempt to convert the Page class object into a IRequiresSessionState interface object, if the conversion is unsuccessful, The session object is not loaded, and if the conversion succeeds it assigns it to the session property of the Page object; (Page.HttpContext.HttpSessionState)

(Page life cycle)
First step: Create a control tree
In 11 to 12 events. Execute the ProcessRequest method of the page class (the general handler); First, according to each control on the page and we write static tags to create these basic, and now is not a formal creation, has not put the control new out, it is new when the first time;
Execute _buildcontroltree () This method, the internal method is to create the entire page control, the ordinary C # generation is compiled into a method body inside;

Step Two:
Determines whether the current request is ispostback or not, and it is implemented by ViewState; As long as the ViewState is not NULL, it is sent back, and the result is true.

Step Three:
An event before the beginning of the Preinint ()
Init () Actual initial: Initializes the controls on the control tree to an instance and assigns the default values; Inside the method is the implementation of a recursive initial normalization;
InitComplete () Early completion of the

Fourth Step:
Load viewstate, load the state of the page, parse the ViewState in the hidden field
After this parsing is complete, the next step:

Fifth Step:
Processpostdate (): Processing postback data
1: Compare the data submitted by the form with the original state on the control, and then place the control that needs to trigger the change event into a collection to wait for the trigger. (When you need to change the value of a square box, it will change after the changes and before the comparison, will be changed after the control or tags added to the collection, waiting for the change of the event trigger);
2: Assign values from the form to the control.

Sixth step:
Page load
Preload () before loading

Load is the Page_Load () method we use; Here we can get the values in the control

Seventh Step:
After load, execute Processpostdata again: The second time processing the postback data; Why the second time? Allows the value to be processed again in the face load, and once again the control that needs to trigger the change event is placed in the collection; This is the last chance before the event responds: The place that triggered the change of events;

Eighth Step:
LoadComplete () after loading
Trigger events that change the control,

Nineth Step:
Events that trigger the postback postback control

Tenth step:
Prerend () The event before the page renders (that is, the process of converting the server control to HTML code)
Before this approach, it is possible to modify the opportunity that we send to the client in response to the content;

11th Step:
Saves the state of the current page (places the value that needs to be saved in ViewState, which is the hidden field)

12th Step:
Page rendering goes back to the 11th and 12th events

2. Escrow Program: ASPNET runtime

Here's what I did with anti-compilation to see the order of execution inside it:

1:

2:

3:

4:

5:

6:

7:

8:

9:

10:

11:

12:

13:

14:

ASP. NET request principle and page life cycle