Developers familiar with the ASP. NET architecture must be unfamiliar with HTTP modules and HTTP handlers. The role of both is to perform specific processing work on network requests. In. NET core, they are all replaced by middleware (the middle part).
The previous HTTP modules and HTTP handlers were processed as requested:
Now it turns out that:
In a nutshell, middleware completes the original work of HTTP modules and HTTP handlers, but is not a simple subtraction of the two.
Middleware minus is the binding of the Application lifecycle events (Application life cycle event) to the important foundation of the original ASP.
The HTTP modules needs to be bound for HttpApplication events at initialization, so that when events of HttpApplication are triggered, the bound handlers are executed as expected.
public class helloworldmodule:ihttpmodule{Public HelloWorldModule () {} public String ModuleName { get {return "HelloWorldModule";} }//In the Init function, register for HttpApplication//events by adding your handlers. public void Init (HttpApplication application) {application. BeginRequest + = (new EventHandler (this. Application_BeginRequest)); Application. EndRequest + = (new EventHandler (this. Application_EndRequest)); } private void Application_BeginRequest (Object source, EventArgs e) {//Create HttpApplication and Http Context objects to access//request and Response properties. HttpApplication application = (HttpApplication) source; HttpContext context = Application. Context; Context. Response.Write ("
You will then need to register this HTTP Module in the Web. config configuration file.
<configuration> <system.web>
If you use middleware, things become very simple. Discard the IHttpModule interface and HttpModule implementation class, no longer concerned about any event of HttpApplication, but also the annoying Web. config configuration. Work directly in the code in the most concise way.
public void Configure(IApplicationBuilder app, IHostingEnvironment env){ app.Use(async(context, next) =>{ await context.Response.WriteAsync("Beginning of Request\n"); await next.Invoke(); await context.Response.WriteAsync("End of Request\n"); }); app.Run(async (context) => { await context.Response.WriteAsync("Hello World!\n"); });}
Similarly, for HTTP handlers, although there is no need to cancel the dependency on the HttpApplication event, but by comparing the code implementation of the two, middleware will undoubtedly ask the winner.
public class HelloWorldHandler : IHttpHandler{ public HelloWorldHandler() { } public void ProcessRequest(HttpContext context) { HttpRequest Request = context.Request; HttpResponse Response = context.Response; // This handler is called whenever a file ending // in .sample is requested. A file with that extension // does not need to exist. Response.Write("
You still need to register the HTTP handler in the Web. config file.
<configuration> <system.web>
In exchange for middleware's wording:
private static void HandleSample(IApplicationBuilder app){ app.Run(async context => { await context.Response.WriteAsync("Hello Sample"); });}// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.public void Configure(IApplicationBuilder app, IHostingEnvironment env){ app.MapWhen(context => context.Request.Path.Value.EndsWith("sample"), HandleSample);}
Summary of the advantages of using middleware:
- No reliance on HttpApplication.
- No dependency on IHttpModule and IHttpHandler interfaces
- No need to add various configurations in the Web. config file
- Code Simplicity
Finally, we need to add a little difference between middleware and HTTP modules. The order in which the requests and responses are processed in each middleware is reversed, and the sooner the middleware processing the request, the later the response is processed. The order in which the requests and responses are processed in HTTP modules is consistent because each HTTP module request is bound to the response event at the same stage.
. NET Core Development Log--middleware