ASP.NET Web Page In-depth Discussion (1)

zhaozj2021-02-17  57

First, the server script foundation

First, let's review the basic implementation of the web server page first:

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

2. After the server receives the request, send the corresponding server-side page (which is the script) to execute, the script generates the client's response, send back to the client

3. The client browser receives the response of the server, parsing the HTML, presented the graphical web page in front of the user.

For the interaction of the server and client, usually by the following main ways:

1, form: This is the most important way, standardized controls to get the user's input, Form's submission will send data to server-side processing

2, querystring: By transmitting parameters to the server by rear the parameters after the URL, this method is actually the same as the GET method.

3, cookies: This is a relatively special way, usually used for user identity confirmation

Second, ASP.NET

Traditional server scripting languages, such as ASP, JSP, etc., write server scripts, are small and small, are embedded in HTML interpretation or compile execution, execute these code by the server platform to generate HTML; for this similar script, page The living cycle is actually very simple, that is, from the beginning to the end, execute all the code, of course, servlet written in Java can write more complex code, but from the structure, and JSP is nothing difference.

The appearance of ASP.NET breaks this tradition; ASP.NET uses CodeBeHind technology and server-side controls, joining the concept of server-side events, changing the mode written in the scripting language, closer to Window programming, making web programming more simple , Intuitive; but we have to see that ASP.NET itself does not change the basic model of web programming, just encapsulates some details, providing some easy-to-use functions, making code easier to write and maintain; from some extent The way the server is executed is complicated, which is the main body we have to discuss today: ASP.NET Web Page's survival cycle.

Third, ASP.NET request processing mode

We said that the web page of the ASP.NET has not been separated from the web programming mode, so it is still in request -> receiving request -> processing request -> Send a mode in this mode, each time with the client interaction will trigger once A new request, so a Web Page is based on a request.

When IIS receives the request from the client, the request will be handed over to the process of the ASPNET_WP. This process will view if the requested application domain exists. If there is no existence, create one, then create an HTTP runtime (httpruntime) ) To process requests, this runtime "provides a set of ASP.NET runtime services for the current application" (from MSDN).

HTTPRUNTIME will maintain a series of applications instances when processing the request, which is an instance of the Global.asax, which will be stored in an application pool when there is no request (actually The application pool is maintained by another class. HTTPRuntime is just a simple call), and each receives a request, HTTPRuntime gets an idle instance to handle the request. This instance does not handle other requests before the request, after processing It will return to the pool again, "An example is used to handle multiple requests during its survival, but it can only handle a request at a time." (Excerpted from MSDN) When the application instance handles the request, it will Creating an instance of the request page class, performing its ProcessRequest method to handle the request, this method is the beginning of the Web Page lifecycle.

Fourth, ASPX page with codebehind

Before you understand the life cycle of the page, let's explore some relationships between ASPX and CodeBehind.

<% @ Page language = "c #" codebehind = "Webform.aspx.cs" inherits = "mynamespace.webform"%>%>

I believe friends who have used Codebehind technology, this sentence to the top of ASPX should be very familiar, let's have an analysis:

Page language = "c #" This is not to say more.

CodeBehind = "WebForm.aspx.cs" This sentence represents the binding code file

Inherits = "mynamespace.webform" This sentence is very important, it indicates the class name of the page inheritance, that is, the class in the code file in CodeBehind, this class must be derived from system.web.webcontrols.page

From above we can analyze, in fact, CodeBehind is the base class of page (ASPX), here, some friends may ask, when writing ASPX, it is completely embedded in HTML in HTML when writing ASPX Or embed server control, didn't see the so-called "class" shadow?

This problem is actually not complex, friends using ASP.NET programming can go to your system disk: /Windows/microsoft.net/framework/ / Temporary ASP.NET FILES in this directory, this below The temporary file of the ASP.NET application existing on this unit is the name of the application, then go back to the two layers (to ensure unique, ASP.NET automatically generates two layers of subdirectory, and subdirectory The name is randomly), then we will find a lot of link libraries such as "YFY1GJHC.DLL", "Xeunj5u3.dll" and "Komee-bp.0.cs", "9falckav.0.cs" Document, in fact, this is the result of AspX being dynamically compiled by ASP.NET, open these source files. We can find:

Public class Webform_ASPX: MyNamespace.Webform, System.Web.SessionState.irequiresSessionState

This has confirmed our previous statement. Aspx is a subclass of code binding classes. Its name is an ASPX file name plus the "_aspx" suffix. By studying these code we can find that the server control defined in all ASPX is actually defined in all ASPX They are all generated in these codes, and then dynamically generate these codes, the code originally embedded in the ASPX is written in the corresponding position. When a page is first accessed, the HTTP runs with a code generator to parse the ASPX file and generate source code and compile, then the subsequent access directly calls the compiled DLL, which is why ASPX A very slow reason when visiting is visited.

Explain this problem, let's see another question. When we use the code binding, we drag a control in the design page, then switch to the code view, you can use this control directly in Page_Load, since the control is generated in the subclass, why can you be in the parent class? Direct use?

In fact, we can find that whenever you drag a control to the page with vs.net, you will always add a declaration like this:

protected system.web.webcontrols.button button1;

We can find that this field is declared into protected, and the name is consistent with the ID of the control in the ASPX. If you think about it, this question is unlucky. The source code of the ASPX mentioned in front of us is dynamically generated and compiled by the generator. The generator will generate the code of each server control. When it is generated, it will check that the parent class declares this control, if declares It will add a code similar to the following:

THIS.DATAGRID1 = __CTRL;

This __ctrl is a variable that generates the control. At this time it assigns the reference to the control to the corresponding variables in the parent class, which is why the statement in the parent class must be protected (actually available for public), because Guaranteed subclasses can be called.

Then when executing Page_Load, because the parent class's statement has been assigned a value in the initialization code in the subclass, we can use this field to access the corresponding control, understand these, we will not commit the code tied Use a control in the constructor in the file, causing an error in the empty reference, because the constructor is executed first, this time the initialization of the subclass has not started, so the fields in the parent class are null value, as the child When is the class initializes us to put it on the discussion.

"to be continued..."

转载请注明原文地址:https://www.9cbs.com/read-29239.html

New Post(0)