ASP.NET Architecture, Part 1 - An ASP.NET Page's Life Cycle
(Page 6 of 8 )
Let’s examine a page’s life cycle to further our knowledge of ASP.NET pages. Figure 1 illustrates the page’s process from its inception to its destruction.
Figure 1 An ASP.NET page’s life cycle
Each ASP.NET page contains a server-side <form> tag. This tag directs the page to post back to itself when a client submits the form. The Form type events include Load, Draw, Render, and Unload.
ASP.NET controls also render JavaScript to the client, enabling actions such as selecting a specified item from a drop-down list, thereby causing a post back to the server. The ASP.NET runtime also renders a hidden form field to the page and allows it to preserve its state between client requests.
Note: The engagement between client and page in the case of hidden form fields occurs on the client side, rather than on the server.
Because ASP.NET is event driven, client and page interaction allows the page to be reconstructed on the server. It also permits code execution in response to events raised by users and any changes occurring in the hidden fields.
The initial event begins with an HTTP URL client request for rendering a specific page to a client’s browser. The Load event fires next. Here is where the CLR uses reflection to examine the .aspx page and see if the page is called for the first time, or whether this represents a post back through user interaction with a button or some other page control. If the event is a first-time request, the code is converted to a class. Subsequently, the class compiles to an assembly and is stored in a valid Internet Information Server virtual directory where the page can be located. However, if the page is posted back, ASP.NET restores any data residing in hidden fields (ViewState) and passes the information to the server. The control event triggering the post back then fires. At this point, all control events are initiated. The change events fire first; those events are stored in the browser and execute only when the client sends the page back to the server. After a control event fires, the page is rendered to the browser.
Before Page_Unload() unloads the page from server memory, a final event performs any cleanup tasks before the unload method disposes of the page.
NOTE: A dynamically generated assembly is not static. If you modify any application code in the .aspx page, the DLL is regenerated the next time the page is called before storing it again to the disk. Latency is an issue here. For example, in a network, latency is a delay. Latency could be solved by multithreading. The browser will respond to callbacks and DLL regeneration.  Come back this Friday, 27/02/2004, for part two of ASP.NET Architecture. This is chapter six of .NET & J2EE Interoperability, by Dwight Peltzer (McGraw-Hill/Osborne, ISBN 0-07-223054-1, 2004).
Buy this book now.
|
Next: Applying Page Directives >>
More ASP.NET Articles
More By McGraw-Hill/Osborne
/ 25 
