ASP. Net Web Page

I. server script Basics

First, let's review the basic execution method of the Web Server Page:

1. The client sends a request to the server by entering the address in the address bar of the browser.

2. After the server receives the request, it sends it to the corresponding Server Page (that is, the script) for execution. The script generates the client response and sends it back to the client.

3. The client browser receives a response from the server, parses the Html, and displays the graphical web page in front of the user.

For the interaction between the server and the client, the following methods are usually used:

1. Form: This is the most important method. Standard controls are used to obtain user input. Form submission sends data to the server for processing.

2. QueryString: Pass the parameter to the server by adding a parameter after the Url. This method is the same as Form in Get mode.

3. Cookies: this is a special method, which is usually used for user identity confirmation.

II. Introduction to ASP. Net

Traditional server scripting languages, such as ASP and JSP, are similar in writing server scripts. They are embedded in Html to explain or compile and execute code, the server platform executes the code to generate Html. For such scripts, the page life cycle is actually very simple, that is, from the beginning to the end, all the code is executed, of course, Servlet compiled in Java can write more complex code, but in terms of structure, it is no different from JSP.

ASP. the emergence of Net breaks this tradition; ASP. net adopts CodeBehind technology and server-side controls, adds the concept of server-side events, changes the script language writing mode, and is closer to Window Programming, making Web programming simpler and more intuitive; but we can see that ASP. net does not change the basic Web programming mode, but encapsulates some details and provides some easy-to-use functions to make the code easier to write and maintain. To some extent, the method of server execution is complicated. This is the subject that we will discuss today: ASP. net Web Page lifecycle.

Iii. ASP. Net Request processing mode

Let's say, ASP. net Web Page is not in the Web programming mode, so it is still working in the request-> receive request-> process request-> send response mode, every interaction with the client triggers a new request. Therefore, the lifecycle of a Web Page is based on a single request.

When IIS receives a request from the client, it will send the request to the aspnet_wp process for processing. This process will check whether the requested application domain exists. If not, it will create one, then, an Http Runtime (HttpRuntime) is created to process the request. This RunTime "provides a set of ASP for the current application. NET runtime Service (from MSDN ).

HttpRuntime maintains a series of application instances when processing requests, that is, the Global class of the application (global. asax) instances. These instances are stored in an application pool when there is no request (in fact, the application pool is maintained by another class, And HttpRuntime is just a simple call ), every time a request is received, HttpRuntime will get an idle instance to process the request. This instance will not process other requests before the request ends. After the request is processed, it will return to the pool, "An instance is used to process multiple requests within its lifetime, but it can only process one request at a time." (From MSDN)

When an application instance processes a request, it creates an instance of the Request Page class and executes its ProcessRequest method to process the request. This method is the beginning of the Web Page lifecycle.

4. Aspx page and CodeBehind

Before getting to know the lifecycle of the page, we will first discuss the relationship between Aspx and CodeBehind.

<% @ Page language = "c #" Codebehind = "WebForm. aspx. cs" Inherits = "MyNamespace. WebForm" %>

I believe that my friends who have used CodeBehind technology should be very familiar with this sentence at the top of ASPX. Let's analyze it one by one:

Page language = "c #".

Codebehind = "WebForm. aspx. cs" indicates the bound code file.

Inherits = "MyNamespace. webForm is very important. It indicates the class name inherited by the page, that is, the class in the CodeBehind code file. This class must be from the System. web. webControls. page Derivation

From the above analysis, we can see that the classes in CodeBehind are actually the base classes of the page (ASPX). Some friends may ask, when writing ASPX, I embed code in Html or server controls completely in ASP mode. I didn't see the so-called "class" shadow?

This problem is actually not complex. You can use ASP. net Programming friends can go to your system disk: WINDOWSMicrosoft. NETFramework <version> Temporary ASP. under the. NET Files directory, all ASP Files on the local machine are stored below.. Net application temporary file. The subdirectory name is the name of the application, and then two layers (to ensure uniqueness, ASP. net automatically generates two sub-directories with random sub-Directories), and then we will find many similar: "yfy1gjhc. dll, xeunj5u3. dll and the "komee-bp.0.cs", "9falckav. 0. cs "source file, in fact this is ASPX is ASP. net Dynamic compiled results, open these source files we can find:

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

This confirms our previous statement that ASPX is a subclass of the code binding class. Its name is the ASPX file name with the suffix "_ aspx". By studying these codes, we can find that, in fact, all server controls defined in aspx are generated in these codes. When these codes are dynamically generated, the Code originally embedded in ASPX is written in the corresponding position.

When a page is accessed for the first time, a code generator is used during Http runtime to parse the ASPX file, generate the source code, and compile it. Then, the compiled dll is called directly for subsequent access, this is why the first access to ASPX is very slow.

After explaining this question, let's look at another question. When binding code, drag a control on the design page and switch to the Code view to directly use the control in Page_Load. Since the control is generated in the subclass, so why can I use it directly in the parent class?

In fact, we can find that every time VS. Net is used to drag a control to the page, the code binding file will always add a declaration like this:

Protected System. Web. WebControls. Button Button1;

We can find that this field is declared as protected, and its name is the same as the ID of the control in ASPX. Think about it carefully and this problem will be solved. As mentioned above, the source code of ASPX is dynamically generated and compiled by the generator. The generator will generate the code for dynamically generating each server control, it checks whether the parent class declares the control. If it declares the control, it adds a code similar to the following:

This. Maid;

This _ ctrl is the variable that generates the control. At this time, it assigns the reference of the control to the corresponding variable in the parent class, this is also why the declaration in the parent class must be protected (or public), because the subclass must be called.

Then, when executing Page_Load, because the declaration of the parent class has been assigned a value for the initialization code in the quilt class, we can use this field to access the corresponding control and learn about it, we will not commit the mistake of using controls in the constructor in the code binding file, resulting in null reference exceptions, because the constructor is the first to execute, and the initialization of the subclass has not yet started, therefore, the field in the parent class is null. We will discuss the time when the subclass is initialized.