Hi newbies, I'm assuming that you all are already convinced about why you should choose ASP.NET as your web development platform, among several other options available; which again implicitly implies that, you all are well aware of the performance, efficiency, scalability, ease-of-use and other such features of this platform. There are many resources(books, whitepapers, forums, etc) available in the market as well as online, which discusses about those facets of ASP.NET in detail (Check out the resources page to get a list of my personal favorites). So, without any more fuss, let's come to the point.
Today, I talk about ASP.NET page life cycle. As always, I personally believe that, to learn any new technology(or any other thing), stick to the KISS paradigm, where KISS(as I expect, most of you already know) = Keep It Simple Silly. This is the best way to approach a new fish in the sea; and let other complex things come your way naturally during the course of time.
Every ASP.NET web application resides inside an application domain setup by the server(IIS, in most cases) itself. This application domain ensures the separation of concern between other web applications hosted on the same server and which are running simultaneously, so that the resources of each web application remain isolated and concealed from all others. That means, there is no way, a application can interfere in the operation of its neighbor application (and yes, that's a really good thing).
The image below shows an overview of an ASP.NET page life cycle.
Whenever you request a page from the server(by typing a web-address in your browser), the request flow takes place in the following sequence:
- the browser sends the request to the server ==> it tells the server that my boss wants this page, so I don't care how, just send to me, as quick as you can.
- the server receives the request and checks for the assigned handler ==>as soon as the server detects an incoming request, it knows where to send it for further processing.
- the server redirects the request to the ASP.NET handler dll (aspnet_isapi.dll) ==> Mr. Request Handler, please process the reqeust I am sending you, and send me back the output so that I can serve my client.
- the handler then, identifies-analyzes-processes the request and sends its output back to the server which then sends it back to the requesting client's browser ==> Here, Mr. Server, please have this data and send it back to your client, I've setup everything and packed it into the data I'm sending you, so that your client's browser should not have any sort of problem in displaying it.
[Note : REQUEST-HANDLING : a class, ApplicationManager, creates an application domain, and sets up everything else required, for the application to run; which includes things like, HttpContext, HttpRuntime, HttpRequest, HttpResponse, etc. ]
A page is internally generated through a MHPM ( Module, Handler, Page and Module event) request. The sequence of the events that are fired, is tabulated below. This is the most important aspect of ASP.NET page request, and the only thing that you should keep in your mind, from this blog.
Today, I talk about ASP.NET page life cycle. As always, I personally believe that, to learn any new technology(or any other thing), stick to the KISS paradigm, where KISS(as I expect, most of you already know) = Keep It Simple Silly. This is the best way to approach a new fish in the sea; and let other complex things come your way naturally during the course of time.
Every ASP.NET web application resides inside an application domain setup by the server(IIS, in most cases) itself. This application domain ensures the separation of concern between other web applications hosted on the same server and which are running simultaneously, so that the resources of each web application remain isolated and concealed from all others. That means, there is no way, a application can interfere in the operation of its neighbor application (and yes, that's a really good thing).
The image below shows an overview of an ASP.NET page life cycle.
Whenever you request a page from the server(by typing a web-address in your browser), the request flow takes place in the following sequence:
- the browser sends the request to the server ==> it tells the server that my boss wants this page, so I don't care how, just send to me, as quick as you can.
- the server receives the request and checks for the assigned handler ==>as soon as the server detects an incoming request, it knows where to send it for further processing.
- the server redirects the request to the ASP.NET handler dll (aspnet_isapi.dll) ==> Mr. Request Handler, please process the reqeust I am sending you, and send me back the output so that I can serve my client.
- the handler then, identifies-analyzes-processes the request and sends its output back to the server which then sends it back to the requesting client's browser ==> Here, Mr. Server, please have this data and send it back to your client, I've setup everything and packed it into the data I'm sending you, so that your client's browser should not have any sort of problem in displaying it.
[Note : REQUEST-HANDLING : a class, ApplicationManager, creates an application domain, and sets up everything else required, for the application to run; which includes things like, HttpContext, HttpRuntime, HttpRequest, HttpResponse, etc. ]
A page is internally generated through a MHPM ( Module, Handler, Page and Module event) request. The sequence of the events that are fired, is tabulated below. This is the most important aspect of ASP.NET page request, and the only thing that you should keep in your mind, from this blog.
Section | Event | Description |
HttpModule | BeginRequest | This event signals a new request; it is guaranteed to be raised on each request. |
HttpModule | AuthenticateRequest | This event signals that ASP.NET runtime is ready to authenticate the user. Any authentication code can be injected here. |
HttpModule | AuthorizeRequest | This event signals that ASP.NET runtime is ready to authorize the user. Any authorization code can be injected here. |
HttpModule | ResolveRequestCache | In ASP.NET we normally use outputcache directive to do caching. In this event ASP.NET runtime determines if the page can be served from the cache rather than loading the patch from scratch. Any caching specific activity can be injected here. |
HttpModule | AcquireRequestState | This event signals that ASP.NET runtime is ready to acquire session variables. Any processing you would like to do on session variables. |
HttpModule | PreRequestHandlerExecute | This event is raised just prior to handling control to the HttpHandler. Before you want the control to be handed over to the handler any pre-processing you would like to do. |
HttpHandler | ProcessRequest | Httphandler logic is executed. In this section we will write logic which needs to be executed as per page extensions. |
Page | Init | This event happens in the ASP.NET page and can be used for :- · Creating controls dynamically, in case you have controls to be created on runtime. · Any setting initialization. · Master pages and them settings. In this section we do not have access to viewstate , postedvalues and neither the controls are initialized. |
Page | Load | In this section the ASP.NET controls are fully loaded and you write UI manipulation logic or any other logic over here. |
Page | Validate | If you have valuators on your page, you would like to check the same here. |
Render | It’s now time to send the output to the browser. If you would like to make some changes to the final HTML which is going out to the browser you can enter your HTML logic here. | |
Page | Unload | Page object is unloaded from the memory. |
HttpModule | PostRequestHandlerExecute | Any logic you would like to inject after the handlers are executed. |
HttpModule | ReleaserequestState | If you would like to save update some state variables like session variables. |
HttpModule | UpdateRequestCache | Before you end if you want to update your cache. |
HttpModule | EndRequest | This is the last stage before your output is sent to the client browser. |
Let me repeat once again, to have a good knowledge of the ASP.NET events, is a great asset to have, in your web-development career. You will always need to use one or more of them, in one situation or the other. We will delve into the complexities and scenarios where you might have to use those events, in our coming sessions. So, I guess this is more than you can take for this session. See you all next time. Cheers.Live life!!!
