ASP.NET Core 1.0中的管道-中间件模式

ASP.NET Core 1.0借鉴了Katana项目的管道设计(Pipeline)。日志记录、用户认证、MVC等模块都以中间件(Middleware)的方式注册在管道中。显而易见这样的设计非常松耦合并且非常灵活，你可以自己定义任意功能的Middleware注册在管道中。这一设计非常适用于“请求-响应”这样的场景——消息从管道头流入最后反向流出。
在本文中暂且为这种模式起名叫做“管道-中间件（Pipeline-Middleware)”模式吧。
本文将描述”管道-中间件模式”的“契约式”设计和“函数式”设计两种方案。
一、什么是管道-中间件模式？



在此模式中抽象了一个类似管道的概念，所有的组件均以中间件的方式注册在此管道中，当请求进入管道后：中间件依次对请求作出处理，然后从最后一个中间件开始处理响应内容，最终反向流出管道。
二、契约式设计
契约式设计是从面向对象的角度来思考问题，根据管道-中间件的理解，中间件(Middleware)有两个职责：
管道(Pipeline)抽象应该能够注册中间件(Middleware)：
实现IApplicationBuilder：
Run()方法将依次枚举Middleware并对消息的请求和响应进行处理，最后返回最终处理过的消息。
接下来需要实现一个Middleware：
为了将Middleware注册进管道，我们还可以写一个扩展方法增加代码的可读性：
写个测试看看吧：



写第二个Middleware：
编写测试：



三、函数式设计方案
此方案也是Owin和ASP.NET Core采用的方案，如果站在面向对象的角度，第一个方案是非常清晰的，管道最终通过枚举所有Middleware来依次处理请求。
站在函数式的角度来看，Middleware可以用Func<Context, Context>来表示，再来看看这张图：



一个Middleware的逻辑可以用Func<Func<Context, Context>, Func<Context, Context>>来表示，整个Middleware的逻辑可以用下面的代码描述：
这一过程是理解函数式方案的关键，所有Middleware可以聚合为一个Func<Context,Context>,为了易于阅读，我们可以定义一个委托：
给定初始RequestDelegate，聚合所有Middleware：
自定义一个函数式Middleware：
所有代码提供下载：https://git.oschina.net/richieyangs/Pipeline.Middleware.git

相关文章

ASP.NET Core 1.0 入门——Application Startup

ASP.NET Core 1.0 入门——了解一个空项目

ASP.NET Core 1.0 部署 HTTPS （.NET Framework 4.5.1）

.NET Core 1.0、ASP.NET Core 1.0和EF Core 1.0简介

云服务器下ASP.NET Core 1.0环境搭建（包含mono与coreclr）

使用VS Code开发ASP.NET Core 应用程序

dotnet run是如何启动asp.net core站点的

ASP.NET Core提供模块化Middleware组件

“dotnet restore"和"dotnet run"都做了些什么？

探秘 dotnet run 如何运行 .NET Core 应用程序

.NET Portability Analyzer 已开源

.NET跨平台之旅：corehost 是如何加载 coreclr 的

ASP.NET Core 行军记 -----拔营启程

如何迁移#SNMP到.NET Core平台的一些体会

原文地址：http://www.cnblogs.com/richieyang/p/5315390.html

.NET社区新闻，深度好文，微信中搜索dotNET跨平台或扫描二维码关注