Asp. NET application life cycle Amusing (iii) HttpModule

In the previous article, we talked about P_module, a capable programmer of HttpModule, who intervened in the entire application-level event processing through the authorization given to the project manager HttpApplication. All httpmodule have to implement the IHttpModule interface, so we look at the definition of IHttpModule:

Namespace system.web

{

public Interface IHttpModule

{

void Dispose ();

void Init (httpapplication context);

}

}

As you can see, HttpModule mostly does two things, one that everyone understands to release the resource Dispose (), and the other to initialize. With what initialization? Of course it's HttpApplication. As already said, P_module programmer is authorized by the project manager HttpApplication, here we can see that the initialization method parameter is HttpApplication object, then HttpModule is How to handle application-level events ? And look at:

We can see that the project manager HttpApplication but the real decentralization ah, it is very much believe that p_module can do these things, so in the initialization method init (HttpApplication context), the programmer p_ Module can register a lot of events, such as commonly used beginrequest, EndRequest, AuthenticateRequest, AuthorizeRequest and so on, there are some other infrequently used events we will not repeat. All in all, HttpModule is strong enough to be involved in all events that can intervene throughout the application cycle---because it is fully licensed. The following is a sample code for registering the BeginRequest event:
Public void Init (httpapplication context)

{

Context. endrequest+= New EventHandler (context_endrequest);

}

Private void context_endrequest (object sender, EventArgs e)

{

Do something when the request end

}

So here, let's clarify a question: in the ASP . Amusing ( a) of the net application life cycle , we used to refer to the following "P_handler Confidently smiled and returned the box to the project manager (HttpApplication object)", which is not entirely accurate. In fact, P_module is already a very advanced programmer, and if necessary (registering the EndRequest event) is going to review the work of a junior programmer P_handler, This review event is the endrequest of HttpApplication. Of course, sometimes do not review directly to HttpApplication, so we come to the conclusion:ASP. NET request processing is based on the pipeline model, request from the pipeline to go in, after the HttpModule of some column processing, to the head of the HttpHandler re-processing, and finally through the pipeline back to the original path. Only one request HttpHandler, and HttpModule can have several. (PS:--! It's nonsense, it's better than anyone to write on Msnd .

In general, P_module senior programmers are mostly from the project manager HttpApplication that authorization (incoming HttpApplication parameters) to handle some of the important events at the application level, which run through the entire application life cycle. We often use the HttpModule that comes with ASP., and sometimes we use custom HttpModule. Asp. NET-brought Httpmodul can be found in the following directory: C:\windows\microsoft.net\framework\v2.0.50727\config/web.config

Our own custom HttpModule are written in our application's Web. config file, which is also under the <HttpModules></HttpModule> node, and is not different from the automatic configuration of the system:

Can see the,

Simply say what's sessionstate. SessionState is a mechanism for ASP. NET processing session, simply is it through the management session storage location, to optimize the session performance and security, to avoid browser disable cookies when the session is lost. Asp. NET allows the session to be stored in three locations: aspnet_wp.exe (it crashes session is lost), Aspnet_state.exe (separate stateserver), SQL Server (in the database). For sessionstate's content, please refer to other related articles, I will write it myself later.

The book belongs to the story, then we get two lines of useful code by deserializing SessionStateModule:

public void Init (HttpApplication app)

{

Sessionstatesection sessionstate = Runtimeconfig.getappconfig (). sessionstate;

Read the sessionstate configuration from the config file

This. Initmodulefromconfig (app, sessionstate);

Initialize SessionStateModule events that need to be handled

Other Code

}

The first line reads the configuration of the sessionstate from the Config file (node <configuration><system.web><sessionState> content below, Configure how to store information such as session, the second line initializes the event that SessionStateModule needs to handle, and we'll see what Initmodulefrommodule did:

Private void initmodulefromconfig (HttpApplication app, sessionstatesection config)

{

If (config. Mode! = Sessionstatemode.off)

{

App. Addonacquirerequeststateasync (New BeginEventHandler (this. beginacquirestate), Newendeventhandler (this. endacquirestate));

App. ReleaseRequestState + = new EventHandler (this. onreleasestate);

App. EndRequest + = new EventHandler (this. onendrequest);

}

}

As we can see, in the first line of code, HttpApplication adds the handling of several events of Onacquirerequeststate, and the second line adds the processing method when sessionstate is released. The third line adds the processing method when the request is contacted. SessionStateModule internal how to deal with We do not do the details here, but we can clearly see that sessionstatemodule processed the application-level time, including sessionstate's acquisition, release, and the end of the request. We did not find it handling the event that started the request, but we were sure it was capable of doing it, but it was not necessary to do so in such a situation. The following list of events for HttpApplication is listed in execution order for reference:

1. beginrequest//Start

2. AuthenticateRequest //verification

3. AuthorizeRequest //Authorization

4. acquirerequeststate //Get request State

5. releaserequeststate //release request state

6. Updaterequestcache //update cache

7. Logrequest. This event supports only. NET 3.0 and IIS7 integration modes

8. EndRequest //End

All HttpModule (both custom and system-brought in) have the ability to handle these events and thus have an impact on the application, and it seems that the P_module programmer is very bull, and it makes sense that the project manager trusts it and authorizes it.

Then P_module as a senior programmer, its own knowledge accumulation is very strong, its learning ability can not be ignored. It can learn (create) some new abilities (custom module), the classic example is that it can add some text to each page by its Internet vibe; Here I simply explain a p_ I used. Module self-built example of closing nhibernatesession in the endrequest event:

First, we create a class Hibernateutil, inherit the interface IHttpModule, and implement the interface method:

Public class Hibernateutil : IHttpModule

{

public void Dispose ()

{

}

public void Init (HttpApplication context)

{

}

}

Then, register the endrequest event:

Public void Init (HttpApplication context)

{

Context. endrequest+= New EventHandler (context_endrequest);

}

Private void context_endrequest (object sender, EventArgs e)

{

CloseSession ();

}

Finally, configure Web. config:

At this point, we have completed a custom HttpModule. This small example is not difficult, mainly to illustrate the httpmodule of the creation process and methods, and this article is also not very difficult, I hope that everyone can help, welcome to shoot bricks, less throwing eggs, very expensive, thank you! ^_^

Asp. NET application life cycle Amusing (iii) HttpModule