在這種情況下，ASP.NET Core 向此類常規(guī) ASP.NET 開發(fā)者傳達(dá)的價(jià)值主張是什么呢？

這一全新平臺(tái)最初可能看起來完全不同，就像有人突然偷偷地動(dòng)了你的奶酪一樣。ASP.NET Core 是根據(jù)較為新式的做法重新生成的全新產(chǎn)品。

此產(chǎn)品可能會(huì)也可能不會(huì)提升你的編程能力和滿足客戶需求的能力。實(shí)際上，沒有人可以代表你回答這個(gè)問題。本專欄將撥開任何大肆宣傳、基準(zhǔn)和技術(shù)重點(diǎn)的迷霧，直奔討論的要旨。

如果你繼續(xù)使用當(dāng)前平臺(tái)，那么 ASP.NET Core 的哪些方面可以吸引你的注意？

框架中采用的常見做法

ASP.NET 團(tuán)隊(duì)成員在設(shè)計(jì)原始 ASP.NET 框架時(shí)，采用了 Active Server Pages 的大多數(shù)最佳做法，并在新框架中采用了這些做法。

在此過程中，他們還引入了許多新內(nèi)容，如編譯代碼和托管代碼、自動(dòng)回發(fā)和服務(wù)器控件。ASP.NET Core 采用同一演化模式。

常見開發(fā)做法（如初始加載配置數(shù)據(jù)、依賴關(guān)系注入、NuGet 包、基于聲明的身份驗(yàn)證和 Razor 改進(jìn)）是新框架的原生特性。新框架還具有不同的啟動(dòng)過程、更為模塊化的請(qǐng)求響應(yīng)中間件，以及用于定義控制器和視圖的略為靈活的基礎(chǔ)結(jié)構(gòu)。

ASP.NET Core 還是跨平臺(tái)框架，可方便你開發(fā)并在 Windows、macOS 和 Linux 上托管應(yīng)用程序。這樣一來，ASP.NET Core 會(huì)強(qiáng)制你編寫更優(yōu)質(zhì)的代碼，即默認(rèn)強(qiáng)制實(shí)現(xiàn)其他一些水平的關(guān)注點(diǎn)分離。你也可以通過自律實(shí)現(xiàn)此目標(biāo)。

對(duì)于任何形式的新開發(fā)，ASP.NET Core 絕對(duì)是理想之選。

然而，作為全新的框架，一些初始成本是不可避免的： 所有團(tuán)隊(duì)成員都必須精通此框架。此外，所有成員還必須精通“模型-視圖-控制器 (MVC)”應(yīng)用程序模型。

并不是所有可標(biāo)記為新開發(fā)的框架都是全新的。可取的做法是，重用現(xiàn)有代碼塊，或至少利用所掌握的現(xiàn)有技能（即數(shù)據(jù)訪問或安全技術(shù)）。這樣做的現(xiàn)實(shí)可能性有多大？ 針對(duì)這一點(diǎn)，ASP.NET Core 分為兩種類型。

ASP.NET Core 的類型

圖 1 展示了用于新建項(xiàng)目的 Visual Studio 2015 對(duì)話框。（與 Visual Studio 2017 對(duì)話框基本相同。）

圖 1：在 Visual Studio 中新建 ASP.NET Core 項(xiàng)目

第一個(gè)模板可創(chuàng)建經(jīng)典的非 Core 項(xiàng)目。另外兩個(gè)模板可創(chuàng)建定位不同 .NET Framework 的 ASP.NET Core 項(xiàng)目。這是探索 ASP.NET Core 未知領(lǐng)域過程中遇到的第一個(gè)十字路口。

選擇使用完整的 .NET Framework 可以訪問任何現(xiàn)有 .NET 類庫，但僅限為在 Windows 和 IIS 上托管。圖 2 總結(jié)了兩種類型的區(qū)別。

圖 2：ASP.NET Core 兩種類型的根本區(qū)別

無論選擇哪個(gè)版本的 .NET Framework，使用 ASP.NET Core 都會(huì)在新的運(yùn)行時(shí)環(huán)境中公開代碼，此環(huán)境整合了基于 system.web 的 MVC 運(yùn)行時(shí)與由 OWIN 原則驅(qū)動(dòng)的 Web API。

與 IIS 分離

近年來，Web API 框架試圖解決瘦服務(wù)器的高需求問題，此類服務(wù)器能夠向任何啟用了 HTTP 的客戶端公開 RESTful 接口。

Web API 將應(yīng)用程序模型與 Web 服務(wù)器分離開來，形成了 OWIN 規(guī)范，即一組 Web 服務(wù)器和應(yīng)用程序互操作規(guī)則。然而，Web API 需要主機(jī)，當(dāng)在 ASP.NET 應(yīng)用程序上下文中托管時(shí)，它會(huì)直接將另一個(gè)運(yùn)行時(shí)環(huán)境添加到內(nèi)存占用中。

這是整個(gè)行業(yè)向最簡化 Web 發(fā)展的產(chǎn)物。最簡化 Web 服務(wù)器是用于盡快獲取內(nèi)容的 HTTP 終結(jié)點(diǎn)，只是在一些業(yè)務(wù)邏輯的基礎(chǔ)上添加了瘦 HTTP 層。最簡化服務(wù)器只需根據(jù)需要處理請(qǐng)求，并返回響應(yīng)（無開銷，業(yè)務(wù)邏輯除外）即可。

雖然可以在一定程度上進(jìn)行自定義，但目前的 ASP.NET 運(yùn)行時(shí)環(huán)境并不旨在處理類似方案。

將 ASP.NET 環(huán)境與宿主環(huán)境分離開來是 ASP.NET Core 的主要變化，也是后續(xù)許多應(yīng)用程序級(jí)變化的原因所在。

應(yīng)用程序啟動(dòng)

新建項(xiàng)目后，你首先會(huì)注意到缺少 global.asax 文件，但有 program.cs 文件。令人震驚的是，ASP.NET Core 應(yīng)用程序是由 .NET 驅(qū)動(dòng)程序工具啟動(dòng)的簡單控制臺(tái)應(yīng)用程序 (bit.ly/2mLyHxe)。

.NET 工具是多平臺(tái)支持的關(guān)鍵。一旦命令行工具（和 .NET Core 框架）可用于新平臺(tái)，那么托管便會(huì)簡化為連接 Web 服務(wù)器和工具。在 IIS 控制下，發(fā)布是通過特別模塊 .NET Core Windows 服務(wù)器托管包完成 (bit.ly/2i9cF4d)。

在 Apache 控制下，發(fā)布時(shí)通過配置文件在 Ubuntu 服務(wù)器上實(shí)現(xiàn)。有關(guān)示例，請(qǐng)?jiān)L問bit.ly/2lSd0aF。

實(shí)際的 Web 服務(wù)器起到反向代理的作用，并通過配置的端口與控制臺(tái)應(yīng)用程序進(jìn)行通信?？刂婆_(tái)應(yīng)用程序是在另一個(gè)更簡單的 Web 服務(wù)器的基礎(chǔ)上構(gòu)建而成，此服務(wù)器用于接收請(qǐng)求，并觸發(fā)內(nèi)部應(yīng)用程序管道來處理這些請(qǐng)求。下面的代碼就執(zhí)行此任務(wù)：

varhost = newWebHostBuilder() .UseKestrel() .UseContentRoot(Directory.GetCurrentDirectory()) .UseIISIntegration() .UseStartup<Startup>() .Build();Host.Run();

Kestrel 是接收入站請(qǐng)求并通過管道處理這些請(qǐng)求的 ASP.NET Web 服務(wù)器的名稱。只有為 IIS 托管時(shí)，才需要在代碼片段中調(diào)用 IIS 集成模塊。

推薦對(duì) ASP.NET Core 應(yīng)用程序使用反向代理主要是為了提高安全性，因?yàn)?Kestrel 內(nèi)部 Web 服務(wù)器（目前）并不包含可防止分布式拒絕服務(wù) (DDoS) 等攻擊發(fā)生的篩選器。從純功能角度來看，不一定需要啟用反向代理。

如上所述，ASP.NET Core 應(yīng)用程序中不再有 global.asax 文件，web.config 文件的作用也被大大削弱。實(shí)際上，它只起到讓 IIS 能夠代表應(yīng)用程序執(zhí)行某任務(wù)（如響應(yīng)生成一些靜態(tài)錯(cuò)誤頁面）的作用。關(guān)鍵任務(wù)（如配置錯(cuò)誤處理、日志記錄、身份驗(yàn)證和存儲(chǔ)全局配置數(shù)據(jù)）都是通過啟動(dòng)類操控的新 API 完成。

啟動(dòng)類

啟動(dòng)類至少包含主機(jī)將在初始化階段調(diào)用的一些方法：

publicclassStartup{ publicvoidConfigureServices(IServiceCollection services) publicvoidConfigure(IApplicationBuilder app) { app.Run( async(context) => { awaitcontext.Response.WriteAsync(DateTime.Now) }); }}

通過 ConfigureServices 方法，可以聲明應(yīng)用程序?qū)⑹褂玫南到y(tǒng)服務(wù)。從技術(shù)角度來講，此為可選方法，但我認(rèn)為在任何實(shí)際方案中都有必要使用此方法。

傳統(tǒng)的 ASP.NET 開發(fā)者可能會(huì)感到震驚的是，即使是使用 MVC 應(yīng)用程序模型也必須進(jìn)行顯式聲明和啟用。不過，這一事實(shí)衡量了 ASP.NET Core 對(duì)模塊化的重視程度：

publicvoidConfigureServices(IServiceCollection services){ services.AddMvc();}

在方法 Configure 中，可以配置先前請(qǐng)求的任意服務(wù)。例如，如果請(qǐng)求了 ASP.NET MVC 服務(wù)，可以在方法 Configure 中指定支持的路由列表。

請(qǐng)注意，還需要進(jìn)行顯式調(diào)用，才能啟用內(nèi)部 Web 服務(wù)器來響應(yīng)生成靜態(tài)文件，包括 jQuery 和 Bootstrap 等常見文件：

publicvoidConfigure(IServiceCollection services){ app.UseStaticFiles(); app.UseMvcWithDefaultRoute(); ...}

還可以在啟動(dòng)類中配置應(yīng)用程序中間件。中間件是一個(gè)新詞，在概念上與目前 ASP.NET 的 HTTP 模塊有相當(dāng)程度的重疊。在 ASP.NET Core 中，中間件的工作方式如圖 3 中所示。

圖 3：ASP.NET Core 中間件

可以注冊(cè)有機(jī)會(huì)預(yù)處理和后處理任何傳入請(qǐng)求的代碼塊。也就是說，每個(gè)中間件都可以注冊(cè)在終止中間件（即啟動(dòng)類的 Configure 方法中的 Run 方法）之前或之后運(yùn)行的代碼。

整個(gè)模型類似于 IIS 的舊版 ISAPI 模型。下面的示例展示了某中間件：

app.Use( async(httpContext, next) =>{ // Pre-process the request// Yield to the next middlewareawaitnext(); // Post-process the request });

中間件是需要使用 HttpContext 對(duì)象并返回 Task 的函數(shù)。中間件組件列表中的終止中間件是 Run 方法。與目前的 ASP.NET 管道相比，ASP.NET Core 管道是雙向的，完全可自定義。此外，管道還默認(rèn)是空的。

最簡化 Web 服務(wù)

不言而喻，如果管道中沒有 Run 方法，那么沒有請(qǐng)求會(huì)生成響應(yīng)。同時(shí)，只需調(diào)用 Run 方法即可生成響應(yīng)。

這表明 ASP.NET Core 應(yīng)用程序管道非常之短。在 ASP.NET WebForm 和 MVC 中，需要先完成許多任務(wù)，然后才能對(duì)每個(gè)請(qǐng)求運(yùn)行你自己的代碼。

例如，解析控制器方法是一個(gè)相當(dāng)長的過程，涉及以操作調(diào)用程序?yàn)橹攸c(diǎn)的整個(gè)子系統(tǒng)。相反，Run 方法是在收到請(qǐng)求之后立即直接調(diào)用。

假設(shè)要?jiǎng)?chuàng)建一個(gè)擁有圖像文件（例如，標(biāo)志）列表的文件服務(wù)器，用于根據(jù)一些輸入?yún)?shù)或設(shè)備屬性返回適當(dāng)大小的圖像。

在目前的 ASP.NET 中，最快速的做法可能是編寫特別 HTTP 處理程序，即通過實(shí)現(xiàn)映射到固定 URL 路由的 IHttpHandler 接口創(chuàng)建的類。

HTTP 處理程序的速度比 ASPX 終結(jié)點(diǎn)和 MVC 控制器更快，因?yàn)樗墓艿栏?xì)。此外，它占用的內(nèi)存比 Web API 終結(jié)點(diǎn)更小，因?yàn)樗恍枰诨?ASP.NET 管道的基礎(chǔ)之上使用另一個(gè) OWIN 管道。（如果 Web API 解決方案在 IIS 外部托管，情況就不是這樣了。）

在 ASP.NET Core 中，創(chuàng)建有效的文件服務(wù)器變得空前簡單和有效。只需編寫附加邏輯（即重設(shè)大小/檢索），然后將邏輯綁定到 ConfigureServices 方法的 Run 方法中：

publicvoidConfigure(IApplicationBuilder app){ app.Run( async(context) => { varcode = context.Request.Query[ "c"]; varsize = context.Request.Query[ "s"]; varfile = FindAndResizeFlag(code, file); awaitcontext.Response.SendFileAsync(file); });}

在此示例中，我假設(shè)使用某自定義邏輯來查找與提供的參數(shù)匹配的服務(wù)器文件名，然后通過 Response 對(duì)象將其返回給調(diào)用方。

無需使用其他任何代碼，無論是可見，還是不可見。坦率地說，這種方法實(shí)際上是再簡單不過了。

無論你對(duì) ASP.NET Core 的直覺情緒如何（懷疑態(tài)度還是青睞有加），ASP.NET Core 都提供了其他任何 ASP.NET 平臺(tái)不曾有的一種特殊功能：創(chuàng)建最簡化 Web 服務(wù)。

同時(shí)，方便你生成最簡化 Web 服務(wù)的同一基礎(chǔ)結(jié)構(gòu)也是能以最低合理開銷響應(yīng)任何請(qǐng)求的最好保證。

總結(jié)

要成為一名高效率的 ASP.NET Core 開發(fā)者，只需熟悉比 WebForm 更新式的應(yīng)用程序模型（即 ASP.NET MVC 或單頁應(yīng)用程序模型）即可。

無論表象如何，ASP.NET Core 的大部分重大變革都體現(xiàn)在運(yùn)行時(shí)環(huán)境中。了解托管模型和中間件就足以運(yùn)用新平臺(tái)了。

最后，它仍是用于創(chuàng)建控制器并呈現(xiàn) Razor 視圖的工具。需要使用不同的 API 來執(zhí)行身份驗(yàn)證、日志記錄和配置等常見任務(wù)，但學(xué)習(xí)起來并不費(fèi)時(shí)。在我看來，挑戰(zhàn)在于如何發(fā)現(xiàn)適合自己的功能。

Dino Esposito 是《Microsoft .NET： 構(gòu)建面向企業(yè)的應(yīng)用程序》（Microsoft Press，2014 年）和《使用 ASP.NET 構(gòu)建新型 Web 應(yīng)用程序》（Microsoft Press，2016 年）的作者。Esposito 是 JetBrains 公司 .NET 和 Android 平臺(tái)的技術(shù)推廣專家，經(jīng)常在全球性行業(yè)活動(dòng)上發(fā)表演講，他在 software2cents.wordpress.com 和 Twitter: @despos.上分享了他的軟件構(gòu)想。深圳網(wǎng)站建設(shè)公司博納網(wǎng)絡(luò)編輯整理。