ASP.NET vNext 是“主機不可知論”，這是什么意思？

Question

根據ASP.NET vNext 教程：

vNext 與主機無關。 您可以在 IIS 中托管您的應用程序，或在自定義進程中自行托管。

如何通過顯示當前 asp.net 主機和新主機之間的區別來深入理解這一點？

Answer 1

ASP.NET 托管的歷史

早在 2002 年，基本上只有一個用於 .NET 平台的 Web 服務器，那就是 IIS。 幾年后，Visual Studio 開發 Web 服務器（“Cassini”，以前是原始 Web Matrix 的一部分）作為開發專用服務器出現了。 但這些最終都使用 System.Web 作為應用程序和 Web 服務器之間的托管層。 System.Web 主機與 IIS 緊密耦合，很難在其他主機上運行。 甚至 VS Dev Web 服務器上的實現也受到限制，因為它只支持某些功能。 因此，對於依賴於 System.Web 的典型 ASP.NET 應用程序來說，仍然只有一個生產質量的“主機”。

快進了大約十年， OWIN作為應用程序和 Web 服務器之間的接口出現了。 這允許任何與 OWIN 兼容的應用程序通過 OWIN 與具有 OWIN 兼容托管層的 Web 服務器進行通信。 微軟將Katana編寫為一種 OWIN 實現，可以在多個服務器上托管 ASP.NET Web API、ASP.NET SignalR 和許多第 3 方框架，包括 IIS（和 IIS Express）、Katana 的自托管服務器和自定義主機（即在自定義應用程序中運行 Katana 的主機）。 還有另一個名為Nowin的 OWIN 實現應該能夠運行與 Katana 相同的應用程序。 這是主機不可知論的一個例子。

現在又快進幾年，出現了ASP.NET vNext ，它遵循與 OWIN 非常相似的模型，具有中間件和主機不可知論。 ASP.NET vNext 還具有適用於 OWIN 中間件應用程序組件的兼容性層。

ASP.NET vNext 主機不可知論

與 Katana 和 OWIN 一樣，ASP.NET vNext 與主機無關。 使用 ASP.NET vNext 編寫的應用程序只知道主機抽象層，例如IApplicationBuilder （以前稱為IBuilder ）接口。 應用程序不直接與 Web 服務器對話。 這種抽象大部分是通過“特性接口”完成的，因此一些服務器可以實現特性，而其他服務器可以選擇不實現。

網絡托管選項

ASP.NET vNext 應用程序可以托管在 IIS、IIS Express、您自己的自定義 EXE、新的跨平台Kestrel服務器上，毫無疑問，未來還會有更多的主機。

Katana 和 ASP.NET vNext 都不是 IIS 或其他主機的替代品，盡管它們都有替代的 Web 服務器。 與 Katana 和 ASP.NET vNext 相比，IIS 支持一些更高級的功能，例如應用程序預熱、更豐富的應用程序生命周期管理（即當應用程序崩潰時要做什么、控制它使用的內存量以及其他類型的限制） 、遠程管理等。

OWIN、ASP.NET vNext 和與主機無關的優勢

我無法談論創建 OWIN 的動機，因為我從來都不是那個團隊的一員。 但是擁有 Web 服務器主機抽象的優點有很多：

• 可以相對容易地在主機之間切換。 例如，通常在可以以最少權限運行的僅開發服務器上本地運行。 然后在部署到生產環境時，可能會使用功能更全面的主機，例如 IIS。 然而，IIS 需要管理權限才能安裝，並不是每個人的工作站都擁有該權限。
• 可以存在更多托管選項。 回到過去，由於 ASP.NET 對 IIS 的密切依賴，只能存在一個主機，因此實際上沒有其他主機的“市場”。
• 通過擁有內存測試主機，某些類型的測試更容易編寫。 這經常用於測試 Web 應用程序的整個堆棧，但沒有任何網絡調用。

ASP.NET vNext 的動機部分列在 ASP.NET vNext 官方網站的入門教程中。 一個簡短的總結是：擁有一個跨平台、開源、並行、按需付費、與主機無關的平台，用於構建 Web 應用程序和服務。 聽起來像是一些營銷的東西，但這些都是系統的關鍵方面。 NodeJS 提供了幾乎完全相同的一組特性，當然，一旦你查看細節，當然會有許多實現差異，毫無疑問還有一些更深層次的哲學差異。 支持這些功能的動機通常是不言自明的。

ASP.NET 的受眾

請注意，這是關於 ASP.NET 的一般受眾，包括從 ASP.NET Web 窗體到 MVC、Web API、SignalR、Katana 和 ASP.NET vNext 的所有內容。 這些框架中的任何一個都適用於任何規模的項目，並且應該可供任何熟練的開發人員使用。 通過查看使用它們的項目的大小可以明顯看出這一點。 這個站點 (StackOverflow.com) 部分使用 ASP.NET MVC 構建，由一些非常高級的開發人員（我假設），但是有許多小得多的站點使用相對新手構建的 MVC。 ASP.NET vNext 是大多數相同框架的未來版本，因此它針對相同類型的應用程序和相同類型的開發人員。

更多信息

有關 ASP.NET vNext 和 OWIN 的更多信息，請查看其中一位開發人員的博客文章： http ://whereslou.com/2014/06/10/asp-net-vnext-moving-parts-owin/

Answer 2

請記住，vNext 仍然是一個顏色非常鮮艷的快速移動對象，就目前的情況而言，它有點“半”主機不可知論。

它定義和應用的中間件規范確實允許一個非常通用的接口來安排程序。 所以你們的發展方式是一樣的。 但是 vNext 應用程序本身就是服務器，並且以一種奇怪的方式，目前需要為您正在使用的服務器類型包含膠水庫。

您可以通過查看必須在project.json文件中提供要使用的服務器類型來觀察這一點。 如果 vNext 項目真的是不可知的，您將在系統級別選擇一個服務器，並從所選服務器指向、掛載或啟動您的應用程序。

由於涉及到生命周期，這有點復雜，在這里完成之后，我鼓勵您前往vNext 項目上的這個 github 問題，我試圖在該項目中提倡真正的解耦設計。