The life cycle of the "recommended" ASP.

When a page request is sent to a Web server, regardless of whether the event was fired by a page or by a page redirection, the page runs a series of events as it is created into the release process. The process of an ASP. NET page from being created to releasing contains 10 events.

(1) Object Initialization init event: The flag for page initialization is the Init event. The controls in the page, including the page itself, are initialized for the first time in their original form. Fires this event on the application after the control tree for the page is successfully created. When the Init event occurs, all controls that are statically declared in the. aspx source file are instantiated and taken to their default values. It should be noted that this is not yet available with view state information. Although the OnInit method can be overloaded, the system does not guarantee that the control instances are created in what order.

(2) Load view: After initialization, the page frame loads the view state (ViewState) of the page immediately. The so-called view state is a collection of name/value pairs, such as the ID of the TextBox control and the Text property value that can be saved. It is generally used to persist information to the server in a round trip, that is, to participate in HTTP requests and responses.

Page view state is stored in the <input type= "hidden" field and is recorded as a value of _viewstae. The view state is automatically maintained through Asp.ne. By overriding the LoadViewState method component, developers can control how the view state is restored and how its contents are mapped to internal state. The LoadViewState method is to get the last state from the ViewState, and follow the structure of the control tree of the page, iterate over the entire tree with recursion, and restore the corresponding state to each control.

(3) Processing postback data: The view state is restored, and the state of each control of the page tree species is the same as the state of the controls when the page was last rendered by the browser. The next step is to update the state of these controls to send to the client.

The postback data processing stage is where each control has the opportunity to update its state so that it accurately reflects the state of the corresponding HTML element in the client. For example, the HTML element for a server TextBox control is <input type=text>, where the TextBox control retrieves the current value of the <input> tag and refreshes its internal state with it in the postback data phase. Each control is responsible for extracting the corresponding value from the data being sent and updating some of its properties. The TextBox control updates the Text property, and the CheckBox control refreshes its checked property. The matching relationship between server controls and HTML elements is determined by their IDs.

The page framework implements the IPostBackDataHandler interface on each control that submits the data, and then fires the LoadPostData event to discover the controls that implement the Ipostbackdatahandle interface through page parsing. This will enable the correct callback data to update the control state. When the control is recognized, ASP. NET updates the correct control by matching the control's unique identifier, which has a name value set and a name-value pair in it. This is one of the reasons why each control needs a unique identifier in all specific pages. Other steps are done by the framework, such as determining whether each identifier is unique in the environment and the basic properties of the control.

The prototype of the Lostpostdata method is as follows:
Public virtual bool LoadPostData (string postdatakey, NameValueCollection postcollection)

Postdatakey is a keyword that identifies a control, which can be understood as a collection of postback data that the control's id,postcollection can understand as a view-state value. The method returns a bool value that, if true, indicates that the control state was changed by a postback, otherwise false. The page framework keeps track of all controls that return true and invokes the Raisepostdatachangeevent event on those controls.

The LoadPostData method is determined by the system: Web.WebControls.Control is defined, and every server control that is added is also from system. Web.WebControls.Control is inherited, so there is no need to intervene in the postback processing of the data.

(4) Load page load: At the end of the postback data processing phase, all controls on the page are updated according to the changes entered on the client. At this point, the OnLoad event is fired on the page. For this event, it is believed that most friends will be familiar with, the Page_Load method in the page generated by Visual Studio.NET is the method of responding to the Load event, and for each request, the Load event will be triggered and the Page_Load method will execute. You can use this method to perform some page initialization, such as preparing the connection string for the database. In the event reference, in order to improve performance, the IsPostBack property of the page class is usually used to determine whether the data is postback.

(5) Postback change notification raisepostdatachanged: As described in (3), after all controls that implement the IPostBackDataHandler interface are updated with the correct callback data, each control has a Boolean ID. Identifies whether the data from the control has been changed or persisted since the last commit. The ASP then searches the page for any identification that shows the control's data being changed and fires the raisepostdatachanged. The Raisepostdatachanged event is not fired until all controls are updated after the Load event occurs. This ensures that the data for other controls has not been manually changed in the Raisepostdatachanged event until the control is updated with the postback data. Although it is also possible to define data change events on a page basis, this event is often used by too much use.

(6) Handling postback event RaisePostBackEvent: When a postback update causes a server-side event to change the data, the object that raises the callback is processed in the RaisePostBackEvent event. The object that initiates the callback is often a control that triggers a callback when a button is clicked or its state changes. For example, the button triggers the music onclick event, the client modifies the text of a text box, sets AutoPostBack to true at the same time, triggers the TextChanged event, and so on.

Many of the code is executed in this event because it is an ideal place to control event-driven logic. To ensure the correctness of the data presented to the browser, the RaisePostBackEvent event is eventually fired after a series of callback events. Based on consistency considerations, a control that crosses changes will not be updated until the function is executed. The work to do in the actual ASP. NET development work is to process the code before this event occurs.

(7) Pre-rendering PreRender: After the postback event is processed, the page is ready to render. This stage is marked by the PreRender event. Each control can take advantage of this good time to perform any last update operations that need to be done before the view state is saved and the output is rendered. The processing of the final request changes to the server's response, and the pre-rendering phase is the change in the state that was made before the final rendering, because it must have more properties to produce HTML, such as the Style property, before rendering a control. This is a typical example, before the pre-rendering, you can change the style of a control, when performing pre-rendering, you can save the style, as the rendering phase display HTML style information.

(8) Save State saveviewstate: The next state is SaveViewState, and in this state all controls and the page itself can refresh the contents of their SaveState collection. The resulting view state is then serialized, hashed, BASE64 encoded, and associated to the vi-emstate hidden from end.

(9) Render view render: Here, the actual page processing of the request is almost over, in the render event, also the calling object is that they render as HTML, and then also collect HTML to send to the customer. After the customer receives the HTML tag, it is reorganized and eventually displayed to the customer. When the render event is overloaded, the developer can create a fixed-value HTML for the browser, at which point any HTML created by the page has not yet taken effect. The Render method uses the HtmlTextWriter object to make parameters and generates HTML for the browser. This is primarily used for the development of custom controls.

(10) Disposition disposed: Perform all final cleanup operations before destroying the control. You must release references to expensive resources at this stage, such as memory exits, database connections, and so on.

(11) Uninstall unload: The last surviving flag of a page is the Unload event, which occurs before the Page object is dismissed. In this event, you can call the Dispose method to free as much of any critical resources that are consumed (for example, files, graphics objects, and database connections).

The life cycle of the "recommended" ASP.