ASP. NET page Object Model

Introduction

Whenever you request an ASP. NET page in IIS, you must always forward the request to the ASP. net http pipeline. An HTTP pipeline is a group of controlled objects that process requests in sequence and convert these requests into common HTML text. The HTTP pipeline entry is the HttpRuntime class. ASP. NET underlying structure for each application domain AppDomain) working process to establish an instance of this class HttpRuntime) Note that a working process can only support one running ASP.. NET application domain ).

The HttpRuntime class selects an HttpApplcation object from the internal program pool and enables it to work when receiving the request. The main task of the Http application manager is to find such a class so that it can process requests. For example, when a. aspx resource is requested, the processing handle is an instance that inherits the class from the Page. The ing table of request resource types and related processing handles is saved in the application configuration file. More specifically, this ing table is defined in the

<Add verb = "*" path = "*. aspx" type = "System. Web. UI. PageHandlerFactroy"/>

An extension can be associated with a handle class. More generally, it is associated with a handle factory class. In all circumstances, the HttpApplication object responsible for processing the request gets an object specifically implemented from the IHttpHandler interface. If the relationship between resources and related processing classes is handled based on the HTTP handle, the returned class directly implements related interfaces. If the resource is bound to a handle factory, it will have to go through another stage: The GetHandler method of the handle factory class that implements the IHttpHandlerFactory interface will return an IHttpHandler-based object.

How does one end a page request process in a cycle or when Http is running? The ProcessRequest method of the IHttpHandler interface has this function. This method is called to represent the object on the requested page. ASP. NET opens a process in the underlying structure to generate output for the browser.

Page class 

The type of the HTTP processing handle for a page depends on the URL. When this URL is accessed for the first time, a new class will be built and dynamically compiled into an assembly. A process that analyzes the aspx file separates the code of this class from the aspx file. By default, this class is added to a namespace called asp, And the URL is used as the class name of this class. For example, if the requested URL is page. aspx, this class is ASP. Page_aspx. This class name can be modified by setting the ClassName attribute of the @ Page preprocessing command.

The base class of the HTTP handle is the Page class. This class defines a set of minimum methods and attribute sets. These methods and attributes are shared by all page processing handles. The Page class implements the IHttpHandler interface.

In another case, the base class for actually processing the Page handle is not the Page class, but another class. This happens when the post-code mode is used. Post-code is a technology that separates C # Or VB. NET code from pages. Page code is a collection of event processing handles and other methods that define various page behaviors. These codes can be defined using the <script runat = server> label in the internal form, or you can use the external class form to write-this is the post-code mode. The Code class is inherited from the Page class, but some other methods are embodied or redefined. After the code class of the page is specified, the Code class is used as the HTTP processing handle.

In other cases, if the PageBaseType attribute of the <pages> section is redefined in the application configuration file, the HTTP processing handle is not based on the Page class. For example: <pages PageBaseType = "Classes. myage, mypage "/>

The PageBaseType attribute specifies the type and assembly of the parent class containing the page processing handle. These classes from the Page class automatically assign a set of common or extended methods and attributes to the processing handle.

Page Lifecycle

Once the HTTP page processing handle is clearly defined, the ASP. NET runtime calls the ProcessRequest method for processing the handle to process the request. Generally, there is no need to change the execution method provided by the Page class.

Page execution starts from the FrameworkInitialize method. This method constructs the control tree for the page. This method is a protected and virtual method of the TemplageControl class. Any handle dynamically generated for the aspx resource overwrites this method. In this method, all the control trees on the page are constructed.

Next, the ProcessRequest method makes the page go through several stages: initialization, loading view status information, returning data, loading Page code, and executing backhaul server events. After that, the page is converted to the display mode: Collect the updated view status, generate HTML code, and transfer it to the console. Finally, the page is uninstalled and all requested services are complete.

In various stages, the page handles events related to web controls, where programmer code can intervene and solve certain problems. Some events are specifically designed for embedded controls and controls that cannot be processed at the. aspx code level.

To solve such an event, a page can clearly register as a suitable handle. However, to have backward compatibility with the original Visual Basic programming mode, ASP. NET also supports the form of implicit events. By default, the page looks for the method name related to the event. If a method that matches the event is found, this method is considered as the event handler. ASP. NET provides six specialized method names: Page_Init, Page_Load, Page_DataBind, Page_PreRender, and Page_Unload. These methods have been defined in the Page class, and they are the handler of the corresponding event. During HTTP runtime, these methods are automatically bound to relevant page events, without the need for programmers to write code that associates events with methods. For example, in the following code, the Page_Load method is associated with the page loading event:

This. Load + = new EventHandler (this. Page_Load );

This automatic identification is controlled by the AutoEventWireup attribute of the @ Page pre-instruction. If this property is set to false, the application must explicitly declare and event-related methods. Pages that do not automatically associate page Event code run faster because they do not need to do too much work on matching. You can disable this attribute in the Visual Studio. NET project. However, the default value is true, which means that the Page_Load method is automatically recognized and associated with related events.

Page execution contains several stages listed in order in the following table. They are marked as application-level events, and may also be protected and redefined:

Phase
Page events
Redefinition Method

Page Initialization
Init

View status Loading

LoadViewState

Return Data Processing

Control implements the LoadPostData method of the IPostBackDataHandler Interface

Page loading
Load

Return Data Change check

Control implements the RaisePostDataChangedEvent method of the IPostBackDataHandler interface.

Return event processing
Return event defined in the control
Control implements the RaisePostBackEvent method of the IPostBackEventHandler interface.

Page pre-return stage

PreRender

Page return stage
Render

Page uninstallation stage
Unload

Some of the stages listed in the above table are invisible at the Page level. They are only used when the server control author writes a class inherited from the Page. Init, Load, PreRender, Unload, And the callback processing events defined in the embedded control constitute the entire lifecycle of the page.

Implementation of each stage 

The first stage of the page lifecycle is initialization. This stage is described by the Init event, which is executed after the control tree is built. In other words, when an Init event occurs, all controls declared statically in the. aspx file are instantiated and assigned the default value. In the Init event, you can initialize any settings required in the page lifecycle. For example, in this phase, the control can load an external version file or create a processing handle for the event. Note that any view status information cannot be used in this phase.

After initialization, the page structure is the page loading view status. The view status is a set of name/value pairs. The data stored in the control or page must be solid throughout the web request process. View status indicates the context of the page. Typically, it stores the status of the controller when the page was last executed on the server. The view status is empty when the first page request at the beginning of the session. By default, the attempt state is saved in a hidden domain, which is automatically added to the page. The name of this hidden field is _ VIEWSTATE. If the LoadViewState method is overwritten-the method declared as protected in the Control class-the component developer can Control the storage of the view state and how it maps to the internal state.

Methods such as LoadPageStateFormPersistenceMedium and the corresponding SavePageStateToPersistenceMedium method can be used to load or save the view status to other storage intermediaries, such as sessions, databases, or files on servers. Unlike the LoadViewState method, the method mentioned above can only be used in the inheritance class of Page.

Once the view status is loaded, the control in the page is given the same status as the last one sent to the browser. The next stage is to update them so that they are consistent with the changes on the server side. In the back-to-back data processing stage, controls update their statuses so that the state of the HTML elements on the client is consistent. For example, the server control TextBox has an HTML Control <input type = text> corresponding to it. In the data return phase, the TextBox Control obtains the <input> label value and uses it to update its internal status. Each control can retrieve its own data from the returned data and update its status. The TextBox Control updates its Text attributes. Similarly, the CheckBox control refreshes their Checked attributes. Server controls and HTML elements are matched by the IDs of the two.

In the last phase of data processing, all page controls reflect the last updated status, which is caused by changes in client input. Next, the Load event will be executed on the page.

There are some controls. If some sensitive attributes change in the two requests, they need to respond to the changes and complete some tasks. For example, if the text of the textbox Control on the client changes, the control triggers the TextChanged event. Based on the data from the client, if one or more attributes of the control change, each control can accurately trigger appropriate events for processing. These controls implement the IPostBackDataHandler interface. The LoadPostData method in this interface is executed after the Load event. By redefining the LoadPostData method, the control can verify the changes in the two requests and trigger related event handlers.

Key events in a page cycle are events that are triggered by client events to execute code segments on the server. For example, when a user clicks a button, the page needs to be returned. This event starts from the collection of Button IDs and values. If the control implements the IPostBackEventHandler interface Button and LinkButton, the page Framework calls the RaisePostBackEvent method. The actual situation of this method depends on the type of the control. In the Button and LinkButton controls mentioned above, this method will look for the Click event handler.

After the return event is processed, the page is ready to be sent out. This phase starts with the PreRender event. This is a good time for controls to execute actions during the period before the view information is saved and the result is sent. The next step is SaveViewState. All spaces and pages themselves Save the set content of the view State. The view status is serialized, hashed, and Base64 encoded and stored in the _ VIEWSTATE hidden field.

The sending mechanism of each control can be changed by redefining the Render method. This method constructs an HTML writer object and uses it to generate HTML code for the control. By default, the Render method in the Page class contains recursive calls to all member controls. The page calls the Render method once for each control and caches HTML output.

The last stage of the page lifecycle is the unmount event, which is triggered before the page object disappears. In this event, you should release any critical resources such as files, graphic objects, and database connections ).

Finally, the browser receives the HTTP Response and displays the page.

Summary
The ASP. NET page object model is a novel model with characteristics because it is based on the event mechanism. A web page consists of controls that have rich HTML-based user interfaces and interact with users through events. Building an event model in the context of a Web application is challenging. It is amazing to associate the events generated by the client with the code on the server. The output is also visible to HTML, but they are modified as needed.

It is important to understand the various stages of the page lifecycle and how page objects are instantiated and used by HTTP runtime.