前言
其實地上本沒有路，走的人多了，也便成了路。 -- 魯迅
就像上面魯迅說的那樣，其實在我們開發(fā)中間件的過程中，微軟并沒有制定一些策略或者文檔來約束你如何編寫一個中間件程序， 但是其中卻存在者一些最佳實踐的方法，大多數(shù)人來使用這種方法來使應用程序變得更加容易理解并且易于維護，這就叫“路”，在2017年，這叫套路。
在掌握了這些套路之后，能夠幫助你迅速的搭建一個中間件的基本框架，并且易于擴展和維護，下面我們就來看看怎么樣從頭開始開發(fā)一個中間件吧。
如果你對 ASP.NET Core HTTP 管道還不太清楚的話，下面這篇文章將有助于你對其進行一個系統(tǒng)的了解：
http://www.cnblogs.com/savorboard/p/aspnetcore-http-pipeline.html
Getting Started
說明： 這只是通常情況下，具體的情況還請使用具體的套路。
Setup 1 創(chuàng)建擴展類
如果你的中間件需要一個向 ASP.NET Core 的 DI 容器中添加默認的一些服務的話，那么你就編寫一個需要擴展類，用來在 Startup.cs 中的 ConfigureServices 中注冊服務。
舉例，Microsoft.AspNetCore.ResponseCompression 這是一個用來壓縮請求內容的一個中間件，那么它就需要一個服務用來處理壓縮相關的東西，所以它擴展了 IServiceCollection 并且添加了自己的 Services。
整個中間件的核心代碼并非在這里，這里只是一個開始，那么有同學可能會問了，什么情況下我們需要提前向一個DI里面注入我們中間件需要的服務呢？ 答案是，如果你不知道或者不確定你需要什么樣的服務的時候，跳過此步驟，進入下一步，再等你需要的時候再回頭來補上就是。
那么，我們先看一下編寫一個擴展Service的靜態(tài)類應該怎么做？
首先，新建一個以 xxxServicesExtensions 文件名結尾的靜態(tài)類，用來編寫注入DI的擴展方法。
類建立完成之后，需要向里面添加內容了。通常情況下，中間件中 Service 的擴展方法都是以 Addxxx(this IServiceCollection services) 開頭來命名。在這里有一個需要注意的地方就是它的命名空間，通常情況下我們使用 using Microsoft.AspNetCore.Builder 這個命名空間。
然后，方法里面就是需要注冊的服務了。假設我們需要向里面注冊一個 IResponseCompressionProvider 和 它的實現(xiàn)類 ResponseCompressionProvider，那么最終的擴展方法可能看起來是這樣的。
using System;
using Microsoft.AspNetCore.ResponseCompression;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.DependencyInjection.Extensions;
namespace Microsoft.AspNetCore.Builder
{
public static IServiceCollection AddResponseCompression(this IServiceCollection services)
{
if (services == null)
{
throw new ArgumentNullException(nameof(services));
}
services.TryAddSingleton<IResponseCompressionProvider, ResponseCompressionProvider>();
return services;
}
}
Setup 2 創(chuàng)建配置類
有的時候，用戶在使用我們編寫的中間件的時候，我們需要向提供者提供一些配置項，這些配置項在中間件執(zhí)行之前用來傳遞一些必要參數(shù)信息或者是一些設置信息。舉個我們熟悉例子，我們在使用 MVC 中間件的時候，可能會看到以下寫法：
// Startup.cs
public void ConfigureServices(IServiceCollection services)
{
var userDefinedFilter = new xxxFilter();
services.AddMvc(x => x.Filters.Add(userDefinedFilter));
}
可以看到，用戶可將一些自定義的 Filter 傳入到中間件的，然后中間件在運行的時候，我們傳入的 Filter 就生效了。
注意，中間件使用的配置項有兩種添加方法，一種是添加到 AddMiddleware(Action<xxxOptions> option) 另外一種是 UseMiddleware<>(Action<xxxOptions> option)，那么這兩種有什么區(qū)別呢？
那么，前者Add中的配置項一般情況下是中間執(zhí)行之前就需要的一些信息，也就是說中間件的啟動就依賴于這些配置項，他放置于容器配置（Add DI Service）的時候添加進去更加方便或者合適的時候使用它，另外一種（后者）是容器已經構建完畢，不需要依賴于容器提供的配置項可以使用此種方式。
同樣的道理，當你自己為你的用戶編寫一個中間件的時候，當你也需要用戶可以自定義一些配置或者需要傳入一些參數(shù)的時候，你也可以這么做。那到底怎么樣做呢？ 我們一起來看看。
首先，我們需要一個 xxxOptions 結尾的配置類，用來配置我們中間件需要的一些配置項。我們還是以上面的壓縮中間件舉例。
public class GzipCompressionProviderOptions : IOptions<GzipCompressionProviderOptions>
{
public CompressionLevel Level { get; set; } = CompressionLevel.Fastest;
GzipCompressionProviderOptions IOptions<GzipCompressionProviderOptions>.Value => this;
}
它其中配置了一個壓縮的等級 CompressionLevel ，這是一個枚舉字段。 然后我們可以看到，這個類它繼承了 IOptions<out T> 接口，這是一個知識點，什么意思呢？ IOptions<out TOptions> 是 ASP.NET Core 新的一個配置體系里面的一個接口，當你實現(xiàn)這個接口之后，ASP.NET Core DI 容器提供了了一個 services.Configure<xxxOptions> 這樣的方法來讓你把配置項注入到容器中，當然你也可以將配置項和 appsetting.json 中的配置關聯(lián)起來，以便于配置一些在運行期可能需要變動信息。更多關于 IOptions<T> 的信息可以看 這里的翻譯。
這個 xxxOptions 類通常情況下會提供一些默認值，也就是說當用戶不提供這些參數(shù)的時候，你需要有一個合理的機制或者默認值來正常運行你的中間件。
假如你的配置項有很多，也就是說還有進一步比較細化的配置，那么你可以做一個封裝，就像MVC的Options類一樣，這樣能夠給你的中間件提供更加合理的維護和擴展。
Setup 3 核心中間件
接下來，就是我們的核心代碼類了，通常情況下會有一個 xxxMiddleware 結尾的類用來處理 HTTP 管道請求中的一些業(yè)務，這個類的構造函數(shù)中已經可以使用在Setup1或者Setup2中向DI容器中注冊的服務了。
按照約定，Middleware 類中需要有一個 Invoke 方法，用來處理中間件的核心業(yè)務，它的簽名如下：
public Task Invoke(HttpContext httpContext);
注意，這是一個約定方法，并沒有接口來約束它。在 Invoke 方法中，是中間件實現(xiàn)的核心代碼。 示例如下：
public class xxxMiddleware
{
private readonly RequestDelegate _next;
public xxxMiddleware(RequestDelegate next)
{
if (next == null)
{
throw new ArgumentNullException(nameof(next));
}
_next = next;
}
public async Task Invoke(HttpContext context)
{
// ......
await _next(context);
return;
}
}
在 xxxMiddleware 這個里面有一個構造函數(shù)參數(shù) RequestDelegate，它是一個委托，代表的需要執(zhí)行的下一個中間件，通常情況下我們會把它放到我們業(yè)務代碼的末尾。
Setup 4 中間件擴展注冊
中間件有三種注冊方法（Run，Map，Use），我們暫不考慮Run和Map，因為他們只適用于很小和少的一些情況
完成了以上工作后，接下來，我們需要把中間件注冊到我們的 ASP.NET Core 的執(zhí)行，這個時候我們需要一個 xxxBuilderExtensions 類，它也是一個靜態(tài)類，注意它的命名空間通常為
Microsoft.AspNetCore.Builder，因為這個用戶在使用我們的中間件的時候就不必再添加額外的命令空間，依靠 Visual Studio 的智能提示就可以很快速的搜索到。我們來看一下示例：
using System;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.DependencyInjection.Extensions;
namespace Microsoft.AspNetCore.Builder
{
public static class xxxBuilderExtensions
{
public static IApplicationBuilder UseResponseCompression(this IApplicationBuilder builder)
{
if (builder == null)
{
throw new ArgumentNullException(nameof(builder));
}
return builder.UseMiddleware<xxxMiddleware>();
}
}
}
Yeoman 一秒鐘
有同學可能會說了，這些套路既然是這樣的，那么有沒有什么代碼生成工具來幫我做這些事情呢？答案是肯定的。
博主已經幫你們把工具做好了，它使用的是當今最流行的腳手架工具 npm 中的 Yeoman 。使用它可以幫助你迅速的搭建一個中間件解決方案代碼模板，讓你專注于業(yè)務開發(fā)。
我已經把這個模板上傳于 Yeoman 的倉庫中，你只需要按照如下命令就可以幫你自動生成一套 ASP.NET Core 中間件解決方案代碼模板了，當然單元測試也包含其中。
npm 工具的安裝相信你自己可以的。下面是安裝 Yeoman 工具和博主的模板工具。
// 安裝 Yeoman 腳手架工具 -g 命令為全局安裝
npm install -g yo
// 安裝博主的 Yeoman(ASP.NET Core Middleware)模板
npm install -g generator-aspnetcore-middleware
然后選擇你需要生成解決方案的文件夾，使用如下命令生成。
yo aspnetcore-middleware
注意：生成的過程中需要輸入你中間件的名稱。按要求輸入即可。
總結
本篇文章主要講述了從頭創(chuàng)建一個 ASP.NET Core 的流程，這適用于大多數(shù)場合，但是并不代表所有的場合，在實際開發(fā)的過程中還需要具體的考慮一下。接著博主提供了一個yo自動化腳手架模板用來快速創(chuàng)建一個中間件解決方案。
如果你覺得這篇文章對你有幫助的話，謝謝你的【推薦】。
如果你對 .NET Core 感興趣可以關注我，我會定期在博客分享關于 .NET Core 的學習心得。
本文地址：http://www.cnblogs.com/savorboard/p/generator-aspnetcore-middleware.html
作者博客：Savorboard
歡迎轉載，請在明顯位置給出出處及鏈接