Asp. NET server control life cycle

1. Initialization This phase mainly accomplishes two tasks: first, initialize the required settings for the lifetime of the incoming Web request, and track the view state. First, the page framework raises the Init event by default and invokes the OnInit () method, which the control developer can override to provide initialization logic for the control. Thereafter, the page framework calls the TrackViewState method to track view state. It is important to note that in most cases, the TrackViewState method implementation provided by the control base class is sufficient. Developers may need to override this method only if the child controls define complex properties.

2. Load view state The primary task of this phase is to check that the server control exists and that it needs to revert its state to the end of its request before processing. Therefore, this process occurs during the page callback process, not the initialization request process. At this stage, the page frame automatically recovers the ViewState dictionary. If the server control does not maintain its state, or if it has the ability to save all its state by default and uses the ViewState dictionary, then the developer can choose not to implement any logic. For situations where data types that cannot be stored in the ViewState dictionary or require custom state management, developers can customize the recovery and management of the state by overriding the LoadViewState method.

3. Processing postback data to enable the control to detect the form data that the client sends back, you must implement the LoadPostData () method of the System.Web.UI.IpostBackDataHandler interface. Therefore, only controls that handle postback data participate in this phase.

4. Load to this stage, the server control in the control tree has been created and initialized, the state is restored, and the form control reflects the client's data. At this point, developers can implement the common logic for each request by overriding the OnLoad () method.

5. Send postback change notification at this stage, the server control raises an event as a signal indicating the change in control state due to postback (so that stage is used for the postback process). To establish this signal, the developer must again use the System.Web.UI.IpostBackDataHandler interface and implement another method, Raisepostbackchangeevent (). The procedure is: if the control state changes due to a postback, LoadPostData () returns True, otherwise false. The page framework tracks all controls that return true and calls RaisePostDataChangedEvent () on those controls.

6. Handle postback Events This phase handles client events that cause postbacks. To facilitate the process of mapping client events to server-side events, developers can implement this logic by implementing the RaisePostBackEvent () method of the System.Web.UI.IpostBackEventHandler interface at this stage. By this approach, the server control will successfully capture postback client events for server-side processing.

7. Pre-render this stage to complete any work that is required before the control is built. This work is typically done by overriding the OnPreRender () method. It is important to note that at this stage you can save changes to the state of the control at the present stage, and the changes made during the rendering phase are lost.

8. Save state if the server control does not maintain state, or if it has the ability to save all its state by default and uses the ViewState dictionary, then the developer does not have to implement any logic at that stage. This is because the process of saving the state is automatic. If the server control requires custom state saving, or the control cannot store special data types in the ViewState dictionary, you need to implement state saving by overriding Saveviesstate ().

9. Rendering represents the process of writing markup text to the HTTP output stream. The developer makes the custom markup text in the output stream by overriding the render () method.

10. Disposition During this phase, the release of references to expensive resources, such as database links, is done by overriding the Dispose () method.

11. The uninstallation is done in the same way as in the previous phase, but the developer typically performs cleanup in the Dispose () method rather than handling the Unload event.