ASP. NET basic Tutorial Study Notes: 1. Architecture

1. The core of ASP. NET is the. NET class. They cooperate with each other to provide services for HTTP requests. Basic Architecture ASP. all the classes in. NET are loaded to ASP. NET workers process application domains, they interact with each other and respond to mutual requests 1. Some classes are defined in the system program, as part of the basic class library, in.. 2. Some classes are loaded to gac3. some classes are loaded from the local program. The local assembly is stored in the virtual directory associated with the application in ASP. the process of building an application in. NET is to construct some classes that interact with existing classes in the Basic Framework. The final result is that many classes work together in one process, and provide services for a request. Process model: ASP. NET worker process (worker process.exe) is a separate worker process separated from the iisprocess inetinfo.exe: aspnet_wp.exe. The asp.net process model has nothing to do with the IIS-related process isolation settings. Many tasks processed by IIS can be completed by asp.net in their own worker processes. Ii. Differences between compilation and interpretation access ASP for the first time. NET Program, the page loading speed is very slow, because the first access needs: 1. Load ASP. NET Worker Process 2. the aspx file performs syntax analysis and is compiled into an assembly. The traditional ASP is to hand over the server code to an interpreter. The interpreter interprets and runs the server script, executes the result, and returns the result. This leads to the efficiency of page generation, mainly including: (1) the efficiency of random interpretation of server scripts is lower than that of pre-compiled code on the server (2) the interpreter should be continuously called, mixed Use of static html and server code efficiency is low ASP. NET web pages are always compiled.. NET class, which is stored in the Assembly. Because the. NET class contains both the server code and static html code, you only need to execute the compiled code when you access a page for the first time. Both compiled components and Embedded Server code are compiled components, so there is no difference in efficiency. Iii. base class inherited by aspx: Page first, let's take a look at the type of the webpage and the base class inherited by the webpage. <div> PageType: <% Response. write (this. getType (); %> <br/> PageBaseType: <% Response. write (this. getType (). baseType); %> </div> the webpage type is ASP. Buildpage_aspx, where buildpage is the custom aspx file name, which replaces "." In the file name. The base class is Start. BuildPage, which is the hidden code file associated with the custom aspx file. We know that all the hidden code files inherit from the Page class. System. Web. UI. Page defines a large majority of asp.net functions for request processing. By default, all. aspx classes are inherited from the Page class. The Page class contains many Members and methods for processing requests. For details, refer to MSDN System. web. UI. page 4. Code hiding the code hiding file mentioned above is to create an intermediate base class between the Page class and the aspx class. The intermediate accumulation directly derives the Page class, the aspx class is derived from the intermediate base class. In this way, you can remove a lot of code from the aspx page. We can use the Inherits attribute of the Page command in the aspx header to set the intermediate base class inherited by the aspx Page. Therefore, the hierarchy of the class is that the Page base class for event processing inherits from the Control class, while the Control class defines four events: Init, Load, PreRender, and Unload. In the lifecycle of a Web page, these four events are successively triggered. Trigger time of these four events: Init event: Load event before restoration of any server state: PreRender event before server state Restoration: after all server events are triggered, Unload is returned before HTML is returned. The most common event after a Web page is generated is the Load event. Here there are two methods to handle the Load event: (1) by default, the AutoEventWireup attribute of the @ Page command in the aspx Page header is true. If the value of this attribute is true, we only need to add a method and the signature required by the EventHandler delegate in the Page_Load, Page_Init, and other naming methods in the Page derived class (usually the code hidden file of the Page. When creating a Page derived class, you can use reflection to find the functions that match these names during initialization, and then create a new delegate and use the function to initialize it and subscribe to related events (2) the AutoEventWireup technique relies on the name of the Method for Finding the type information during running and the sequence of execution events, resulting in a reduction in efficiency. We can also set the AutoEventWireup attribute to false, then rewrite the OnInit virtual function to manually subscribe to the Load event, and copy the following code 1 protected override void OnInit (EventArgs e) 2 {3 this. load + = Page_Load; 4 base. onInit (e); 5} 6 protected void Page_Load (object sender, EventArgs e) 7 {8 if (! IsPostBack) 9 {10 personality. items. add (new ListItem ("male", "man"); 11 personality. items. add (new ListItem ("female", "woman"); 12} 13 Response. write ("test"); 14} 5. shadow copy (shadow copy) in traditional ASP programs, as long as the program is running or loaded, a reference to the group file must be retained, to replace this file, you have to disable IIS. ASP. NET prevents this situation through the shadow copy mechanism provided by CLR, that is, iis does not have to be disabled to update or replace files. When creating a new application domain in. NET, you can configure the Shadow Copy of the Assembly. The AppDomainSetup class (this class initializes AppDomain) provides a Boolean ShadowCopyFiles attribute and a string type CachePath attribute to the outside world. The AppDomain class provides a SetShadowCopyPath () method, this function is used to enable the shadow replication function for application domains. The ShadowCopyFiles attribute enables this mechanism for specific application domains. The CachePath attribute specifies the base Directory of the Shadow Copy. The SetShadowCopyPath method specifies which directory can start shadow replication. ASP. NET creates a separate application domain for each application of the Worker Process. Each domain enables shadow replication of all referenced assembly under the bin directory. The Assembly loader does not load the Assembly from the bin directory, but physically copies the referenced assembly to another separate directory (this directory is specified in the application configuration settings) and loads it from here. This mechanism can also track the source of the assembly, so after updating the files in the bin directory, it will be copied to the Shadow directory again. In addition to shadow replication, asp.net must be able to temporarily create and load an assembly. When referencing aspx for the first time, you must first compile it into an assembly and then load it by asp.net. The application domain supports the dynamic directory (dynamic directory, which is specified by the DynamicBase attribute of the AppDomainSetup class to store dynamically created assembly ).