Asp. NET page life cycle

This paper is a processing model based on IIS6.

What happens when a client page accesses IIS trying to get some information? What happens when a request passes through the HTTP pipeline? This article mainly describes these two processes, that is, IIS processes ASP. NET requests and the page life cycle of ASP.

First, we need to figure out two very important concepts:

1, worker process (w3wp.exe). The worker process manages all requests from the client and gives a response. It is the core of an ASP. NET application under IIS.

2, application pool. It is a container for worker process, IIS5 and previous versions of IIS do not have the concept of application pool. Each application pool corresponds to a worker process that maintains the mapping of the application pool and worker process in IIS metabase. This avoids the IIS5 in the worker process (IIS5 is aspnet_wp.exe, only one process can run at a time) crashes, application the whole crash situation.

After the client sends a resource request to IIS, the following occurs:

1, the server accepts the request

IIS6 distributes the request to the application pool via HTTP. sys in kernel mode (Kernelmodes). This is not a random process and is already registered with HTTP. SYS when the application pool is created, so http. SYS is sent directly to the appropriate application pool when the request arrives. Web Admin Services (WAS) did the work of getting the request from HTTP. SYS and distributing it to the application pool. Application pool directly passes the request to worker process.

2, after the request is passed to the worker process, the worker process initializes the ASP. NET ISAPI (Internet Server applicationprogram Interface), ASP. The ISAPI then loads the CLR to create the managed environment.

( Note: ISAPI is just an interface that acts as an agent, and the primary ability is to look for a handler for that suffix based on the suffix of the request URL)

the ASP . NET ISAPI definitionIn aspnet_isapi.dll , it runs itself in an unmanaged environment. The ASP. NET ISAPI begins with a httpruntime, httpruntime calls the ProcessRequest method (Isapiruntime.processrequest (IntPtr ECB, int Iwrtyp)) To begin processing the request. ProcessRequest based on the Iwrtype that the ISAPI passed in to create differentHttpWorkerRequest,This masks different IIS differences. Next the ProcessRequest method creates the HttpContext, and we use httpcontext.current to access it. After httpruntime created the HttpApplication object (IHttpHandler) with HttpApplicationFactory, All requests will be processed by the corresponding HttpHandler after passing the HttpModule. Before HttpApplicationFactory creates HttpApplication, it looks for all the registers in the config (web. config and machine.config) fileHttpModule, and load the corresponding assembly based on the configuration information, create the corresponding HttpModule through reflection and add the module to HttpApplication _modulecollection the filed. Our request for a application will eventually fall to a HttpApplication object. When a request arrives, ASP. NET finds unused HttpApplication objects in the Httplication pool.

3, after the request passes through the HTTP pipeline, each request is sent to the relevant respective HTTPHANDLER,IIS request processing end.

The HttpHandler is the endpoint of the HTTP pipeline, which generates output for each request. System.Web.UI.Page is such a typical HttpHandler, when we request an ASPX page, this httphandler generates HTML to send back to the client. Look at the signature of the page class:

public class Page:templatecontrol, IHttpHandler

{
}

As you can see, the page class is a HttpHandler.

The whole process is that when a client sends a resource request to the server, the request first arrives at IIS http. sys. HTTP. Sys then sends the request path corresponding to the application Pool. The application pool then sends a request to the worker Process (W3WP.exe) to load the ISAPI Extension, ISAPI creates a HttpRuntime object to process requests through HttpModule and HttpHandler. Then the page life cycle begins.

4, the main stages of the page life Cycle start Page lifecycle include:

page Initialization (Init): Server creates an instance of a server control

Load: The control instance is loaded into the Page object it defines

Pre-output: (PreRender) Changes to the control are updated to prepare the output.

Save (SaveViewState): The state information of the control is saved. Output page (Render): the server creates HTML markup for the control.

processing (Dispose): The primary job is to Dispose, close the database connection, release the file resources, and so on.

Unload (Unload): destroys an instance of a server control

Main events for the page life cycle:

PreInit:

1. CheckIsPostBack 属性
2. Dynamic Settings Master Page
3. Dynamic Settings Theme
4. Set default values for controls (UniqueID, etc.)
5. Re-create the dynamic control (initialize the control), initialize the value of the control

Init: This time occurs when all the controls are initialized and all skin settings are applied later. It is used to read or initialize the properties of a control. It can be used to register events for some of the controls that are not indicated in the ASPX page.
initcomplete: Use of this event for processing tasks, require all initialization to is complete.

preload: Loads the viewstate of the page and all the controls, and then processes all postback data contained in the request instance.

Load: This event is probably the most familiar of all. Note that the Page object recursively invokes the OnLoad event of the child control until the page and all child controls are loaded to completion. This event is primarily used to set the value of a control's properties and to establish a database connection (typically not).

Control Events: This is not much to say, mainly the event that handles the control, such as Click. This also lets us understand that every time we click a button, we actually have to execute the Load event before executing the Click event, generally we use! IsPostBack to avoid performing unnecessary load logic.

LoadComplete: All the controls on the page are loaded and executed later, and for the time being they don't think about what to do ...

PreRender: This is the last event before HTML is generated. The controls in each page have a prerender process. This is where you make the last modification to the HTML results that will be output.

Savestatecomplete: Before this time occurs, all controls and pages have been saved, and any changes to the page or control will not produce left or right. I have no idea what to do for a moment.

Render: It is not an event but a method. The job is to write the HTML back to the client browser.

UnLoad: This happens with every control on the page. In the control, use this event to do cleanup work, such as shutting down the database connection, and so on. The same is done with the page itself, such as closing open files and database connections, or ending logs or other specified work.

It is necessary to note that each request creates an instance of the new page class , so that the field you define in the page cannot pass the value in two request, it needs to be stored using ViewState.

5, HttpHandler sends the results back to IIS,IIS based on the processing of the events in the page life cycle and sends the results back to the client browser.

It is worth noting that during this process the request will be passed through HttpModule again (registering a endrequest event).

Excerpt from: http://www.2cto.com/kf/201008/56499.html

Asp. NET page life cycle