我一直在努力了解ASP.NET 5管道中间件如何真正起作用。据我所知，中间件只是一个 Func<RequestDelegate, RequestDelegate>，这是一个指向接收对下一个请求委托的引用的方法的指针，并返回一个包装下一个请求委托的新方法。当然，我们可以使用类来表示中间件，例如：
public class MyMiddleware
{
private readonly _next;
public MyMiddleware(RequestDelegate next)
{
if (next == null)
{
throw new ArgumentNullException("next");
}
_next = next;
}
public Task Invoke(HttpContext context)
{
// New request delegate code here which can wrap the next one on the pipeline
}
}
自从 RequestDelegate 是一个委托，可以保存对接收方法的方法的引用 HttpContext 并返回一个 Task 该 Invoke method是要返回的请求委托，并且可以访问管道上的下一个委托委托。
然后，在编写中间件时，我们可以访问管道的下一个组件，但我有一个疑问。一开始我认为理想总是以下列方式工作：
- 检查中间件是否可以处理请求
- 如果可以，做任何必须做的事情
HttpContext - 调用管道上的下一个中间件
因此，当我第一次研究这个时，我认为每个中间件应该总是调用下一个。但这样做导致了如上所述的奇怪行为 这个问题。
另外看一些中间件的源代码，我看到其中一些中间件遵循另一个步骤：
- 检查中间件是否可以处理请求
- 如果可以，做任何必须做的事情
HttpContext就这样 - 如果不， 只有不是 打电话给下一个
这是使用中间件的真正想法吗？这方面的正确方法是什么？每个中间件都会执行必须完成的请求，并始终调用下一个或者如果中间件可以处理它不再调用下一个请求的请求？
我相信中间件只有在无法处理请求时才应调用下一个。我认为这是因为如果没有，管道上的中间件之间会有耦合。因此，为了处理请求，中间件需要知道前一个做了什么以避免弄乱一切。这个结论对吗？