Middleware Components(.Net Core) -Part 2
Hi guys, this is basically a Part-2 of middleware component post. We saw, what middle ware component is, and how we can configure the middleware components to form the request pipeline with the ready made components available in the .Net Core platform, in my previous post.
Now, we will look at how we can create our own middleware components.
- In-line middleware
This is perhaps the easy way to create custom middleware components. All you have to do is pass a delegate to the IApplicationBuilder’s Use method.
The arguments to the lambda function are an HttpContext object and a function that is invoked to tell ASP.NET Core to pass the request to the next middleware component in the pipeline. The HttpContext object describes the HTTP request and the HTTP response and provides additional context, including details of the user associated with the request
The second argument to the middleware is the function conventionally named next that tells ASP.NET Core to pass the request to the next component in the request pipeline.
So if we run the application now, and pass the query string parameter as per the code, we can see the output is returned from the custom middleware component along with the default message. Please refer the below screenshot.
And if we do not give the required query string parameter to fire the custom middleware, we will get the default message only:
2. Class based middleware
Defining the custom middleware using lambda expression might be convenient. But overtime, the StartUp class will get cumbersome, and also it will be difficult to reuse the middleware in different projects. In this scenarios, we can consider class based middleware. For this we need to create a middleware class, and make the code changes as shown below:
Middleware classes receive a RequestDelegate as a constructor parameter, which is used to forward the request to the next component in the pipeline. The Invoke method is called by ASP.NET Core when a request is received and receives an HttpContext object that provides access to the request and response, using the same classes that lambda function middleware receives. The RequestDelegate returns a Task, which allows it to work asynchronously.
We can add the class based middleware to the pipeline, as follows:
also now when we run the application with the proper query string values, we will get the output as follows:
3. Branching Middleware
Branching the middleware component is another cool feature out there. Basically we can decide which set of middleware component have to get executed. We group them inside a branch, and execute that branch alone.
The Map method is used to create a section of pipeline that is used to process requests for specific URLs, creating a separate sequence of middleware components.
The first argument to the Map method specifies the string that will be used to match URLs. The second argument is the branch of the pipeline, to which middleware components are added with the Use and UseMiddleware methods. When a URL is matched by the Map method, it follows the branch and no longer passes through the middleware components on the main path through the pipeline.
The output of the above code is as follows:
Here we can see the default message never got executed. That’s the beauty of branching.
Conclusion:
Well, that was all I have to say about custom middleware components. There are lot more scenarios where we can use custom middleware. Give a try of these in your project and let me know how it went.
Thanks for reading!
