---

2017 年 5 月

第 32 卷，第 5 期

此文章由机器翻译。

技術最前線 - ASP.NET 開發人員適用的 ASP.NET Core

由 Dino Esposito | 2017 年 5 月

大部分的核心以多平台為中心的傳聞 aboutASP.NET 體驗它啟用。雖然這是一項龐大的成就，它不一定是加號如果您是一般的 ASP.NET 使用者具有大型的程式碼基底的.NET 4.x 程式碼並不打算保留熟悉的 IIS 和 Windows 環境。在此情況下，針對這類一般的 ASP.NET 開發人員的 ASP.NET 核心價值主張是什麼？

在第一個新的平台可能看起來截然不同，彷彿有人 sneakily 移在夜間您卡達乾酪則在其他地方。ASP.NET 核心是新的從頭開始重新建置，根據較新的做法。這可能會或可能不會增加您的程式設計能力和解決客戶問題的能力。沒有人實際上可以回答這個問題，您的名義。本專欄會嘗試清除任何基準測試，而且技術、 焦點從一開始，並直接跳到獨特的項目。如果您確定是與目前的平台，ASP.NET 核心的哪一面可以擷取您的注意？

工程 Framework 中常見的作法

ASP.NET 團隊成員在設計時原始的 ASP.NET 架構，它們會採用大部分的 Active Server Pages 的最佳作法，以及工程它們到新的架構。如此一來，他們也引進許多新的項目、 例如編譯和 managed 程式碼，自動回傳和伺服器控制項。ASP.NET Core 遵循相同的演化模式。

常見的開發作法，例如初始載入組態資料、 相依性的插入、 NuGet 封裝、 宣告式驗證及 Razor 改進的新架構的原生功能。新的架構也會有不同的啟動程序、 更模組化的要求-回應中介軟體和甚至稍微彈性基礎結構來定義控制器和檢視。ASP.NET Core 也是一種跨平台架構，並讓您開發應用程式並將它裝載在 Windows 中，以及 macOS 及 Linux 上。ASP.NET 核心的方式，會強制您撰寫更好的程式碼分離問題的幾個其他層級會強制預設的位置。它不是，您不能已經完成專業領域，不過任何項目。

任何形式的 greenfield 開發中，ASP.NET 核心是很好的選擇。它是一種全新的架構，有一些無法避免的初始成本︰ 小組成員必須精通使用它。此外，每個人都必須，或精通，與模型-檢視-控制器 (MVC) 應用程式模型。並非所有您可以將標籤標記為 greenfield 開發是全新的。重複使用的現有程式碼或至少現有技術 （也就是資料存取或安全性技術），區塊是比較好。有多少，有可能實際上？ 若要解決此點，ASP.NET 核心有兩種類別。

ASP.NET 核心的類別

在**[圖 1**，您會看到 [Visual Studio 2015] 對話方塊中，若要建立新的專案。（它是基本上是相同的 Visual Studio 2017）。

在 Visual Studio 中建立新的 ASP.NET 核心專案的 [圖 1

第一個範本會建立傳統的非核心專案。其他兩個範本可以建立不同的.NET Framework 的 ASP.NET Core 專案。這是您所面臨之旅，透過 ASP.NET 核心尚未探測的區域領域中的第一個 crossroad。

選擇的是完整.NET Framework 可讓您存取任何現有的.NET 類別庫，但只有 Windows 和 IIS 裝載的限制。[圖 2摘要說明的差異。

[圖 2 種 ASP.NET 核心之間的基本差異

架構	事實
.NET Framework	ASP.NET MVC沒有 WebForms 新的執行階段環境和程式設計 API 以.NET framework 所選的版本為目標的任何程式庫  IIS 裝載
.NET Core	ASP.NET MVC沒有 WebForms 新的執行階段環境和程式設計 API 只有.NET 核心程式庫 跨平台裝載

不論選擇的.NET Framework 中，採用 ASP.NET 核心會公開新的執行階段環境，可統一 system.web 與 Web API 執行階段由 OWIN 原則為基礎的 MVC 執行階段程式碼。

將 IIS

近年來，Web API 架構會嘗試解決需求大量的精簡型伺服器能夠公開給任何 HTTP 啟用用戶端的 RESTful 介面。Web API 分離應用程式模型，從 Web 伺服器，並導致 OWIN 規格，也就是一組 Web 伺服器和應用程式交互操作的規則。Web API，不過，需要主機，當裝載 ASP.NET 應用程式的內容中，只要加入另一個執行階段環境的記憶體使用量。這是業界邁向超級簡單 Web 一次。超級簡單、 最基本的 Web 伺服器是只是精簡型 HTTP 層某些商務邏輯盡快取得內容的 HTTP 端點。超級簡單的伺服器必須執行的所有程序適當地要求並傳回沒有的額外負荷，除了商務邏輯以回應。

雖然有些可自訂，目前的 ASP.NET 執行階段環境不是設計用來處理類似的案例。將 ASP.NET 環境，從裝載環境是您在 ASP.NET 核心和許多後續的應用程式層級變更的原因中找到的主要變更。

應用程式啟動時

建立新專案之後，的首先您會注意到是缺乏 global.asax 檔案以及 program.cs 檔案的目前狀態。因為它可能會 shocking，ASP.NET 核心應用程式是 dotnet 驅動程式工具所啟動的純文字的主控台應用程式 (bit.ly/2mLyHxe)。

Dotnet 工具是以多平台支援的金鑰。適用於新的平台命令列工具 （和.NET 核心架構） 之後，裝載減少 Web 伺服器連接至工具。在 [IIS] 發佈透過臨機操作的模組，.NET 核心 Windows Server 主控封裝達成 (bit.ly/2i9cF4d)。在 Apache Ubuntu 伺服器上，它可透過組態檔。範例，請參閱 bit.ly/2lSd0aF。

實際的 Web 伺服器的反向 proxy 的運作方式和設定的連接埠上的主控台應用程式與通訊。主控台應用程式是根據另一個、 更簡單，Web 伺服器會接收要求，並觸發程序內部的應用程式管線處理它們。下列程式碼會執行工作︰

var host = new WebHostBuilder()
  .UseKestrel()
  .UseContentRoot(Directory.GetCurrentDirectory())
  .UseIISIntegration()
  .UseStartup<Startup>()
  .Build();
Host.Run();

Kestrel 是 ASP.NET Web 伺服器會接收傳入的要求，並透過管線處理它們的名稱。IIS 整合模組中呼叫的程式碼片段，才需要您裝載在 IIS 底下。

內部網頁伺服器 （時間） 就不會包含讓 ASP.NET 核心應用程式只建議主要是基於安全性理由 Kestrel 周圍的反向 proxy 篩選以防止等分散式拒絕服務 (DDoS) 攻擊。從純綷功能性的觀點來看，您完全不需要啟用反向 proxy。

如前所述，不再 global.asax 檔案中沒有 ASP.NET 核心應用程式和 web.config 檔案的角色 （implementation） 會受到影響。事實上，它只提供專門用以啟用 IIS，以執行一些工作，代表應用程式，例如提供一些靜態錯誤頁面。重要事項，例如設定錯誤處理，記錄、 驗證和儲存設定全域資料是透過協調從啟動類別的新 API。

啟動類別

啟動類別包含至少有幾個主應用程式會在初始化階段期間呼叫的方法︰

public class Startup
{
  public void ConfigureServices(IServiceCollection services)
  public void Configure(IApplicationBuilder app)
  {
    app.Run(async (context) =>
    {
      await context.Response.WriteAsync(DateTime.Now)
    });
  }
}

透過 ConfigureServices 方法宣告應用程式的系統服務會使用。技術上來說，這個方法是選擇性的但我覺得那是必要的任何實際的情況。傳統的 ASP.NET 開發人員可能非同小可尋找，甚至使用 MVC 應用程式模型必須明確宣告並啟用。不過，這項事實可提供 ASP.NET 核心嚴重如何取得此量值︰

public void ConfigureServices(IServiceCollection services)
{
  services.AddMvc();
}

在方法中設定，您可以設定任何先前要求的服務。比方說，如果您要求的 ASP.NET MVC 服務，然後將設定中您可以指定支援路由清單。請注意，您也必須明確啟用內部網頁伺服器來提供靜態檔案，包括常見的檔案，例如 jQuery 和啟動程序呼叫︰

public void Configure(IServiceCollection services)
{
  app.UseStaticFiles();
  app.UseMvcWithDefaultRoute();
  ...
}

啟動類別也是您用來設定應用程式的中介軟體的地方。中介軟體是具有重要的概念重疊的目前 ASP.NET HTTP 模組的新詞彙。在 ASP.NET 核心中, 介軟體的運作中所示**[圖 3**。

圖 3 ASP.NET 核心中介軟體

您可以註冊的程式碼區塊，有機會前置和後置處理任何內送的要求，這表示每個中介軟體可以註冊之前或之後結束的中介軟體執行的程式碼 — 啟動類別的設定方法中執行的方法。整體模型很類似 IIS 的舊式 ISAPI 模型。以下是一些範例中介軟體︰

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

中介軟體是採用 HttpContext 物件並傳回工作的函式。Run 方法結束的中介軟體元件清單。相較於目前的 ASP.NET 管線，ASP.NET 核心管線是雙向且可完全自訂。此外，它預設是空的。

超級簡單的 Web 服務

它是了解，而不在管線中執行方法，不要求將曾經產生回應。在此同時，執行方法是您所要產生回應。這會顯示如何簡短管線可以在 ASP.NET 核心應用程式。在 ASP.NET WebForms 和 MVC 中，您的程式碼執行每個要求之前，會發生許多事。解決控制器方法，比方說，是相當長程序，它牽涉到整個子系統中心動作啟動程式。Run 方法，而是，緊接在後面之要求的回條的直接呼叫。

假設您想要建立的檔案伺服器可擁有一份映像檔案 （例如旗標），並傳回適當大小的映像，根據一些輸入的參數或裝置的內容。在現今的 ASP.NET 中，最快的選項可能會撰寫臨機操作的 HTTP 處理常式，藉由實作 IHttpHandler 介面對應至固定的 URL 路由所建立的類別。HTTP 處理常式速度比 ASPX 端點和 MVC 控制器動作由於獎勵的管線。它也具有更小的使用量比 Web API 端點，因為它不需要基本的 ASP.NET 管線之上的第二個 OWIN 管線。（這並不是這樣 IIS 之外裝載 Web API 方案時。）

在 ASP.NET Core 建立有效的檔案伺服器是比以往更容易及比以往更有效率。您的創造額外的邏輯 （也就是調整大小/擷取），並將它繫結至 ConfigureServices 方法的 Run 方法︰

public void Configure(IApplicationBuilder app)
{
  app.Run(async (context) =>
  {
    var code = context.Request.Query["c"];
    var size = context.Request.Query["s"];
    var file = FindAndResizeFlag(code, file);
    await context.Response.SendFileAsync(file);
  });
}

在範例中，我假設有一些自訂邏輯來尋找符合的伺服器名稱提供參數，而且我伺服器將它傳回給呼叫者經由回應物件。沒有其他程式碼，或看看不見，是必要的。坦白說，它無法確實是比這更容易。

無論什麼感覺 ASP.NET 核心，無論您是心存懷疑或 ¡ASP.NET 核心，它提供獨特功能，找不到任何 ASP.NET 平台︰ 建立超級簡單最基本的 Web 服務。在此同時，相同的基礎結構，可讓您建置超簡單的 Web 服務是可提供任何要求額外負荷最小可能合法最佳保證。

總結

身為產能的 ASP.NET 核心開發人員，您只需要熟悉比 WebForms 較新的應用程式模型︰ 這表示在 ASP.NET MVC 或單一頁面應用程式模型。儘管外觀，大部分的 ASP.NET 核心的重大變更是在執行階段環境中。了解的裝載模型與中介軟體，即已足夠讓新的平台發揮作用。最後，它是仍需建立控制器及呈現 Razor 檢視。幾個常見的一些事，像是驗證、 記錄和組態會需要不同的 API，但是學習，只需要一段時間。依我看來，所面臨的挑戰尋找什麼適合您。

---

Dino Esposito是每個 「 Microsoft.NET: 架構的企業應用程式 」 (Microsoft Press，2014年) 和 [使用 ASP.NET 最新 Web 應用程式] (Microsoft Press，2016年)。.NET 和 Android 平台在 JetBrains，並在世界各地的產業活動的技術推廣人員 Esposito 分享軟體的願景 software2cents.wordpress.com和 Twitter: @despos。

感謝下列 Microsoft 技術專家來檢閱這份文件︰ James McCaffrey