Katana 專案概觀
作者： Howard Dierking
ASP.NET 架構已超過十年，而且平臺已啟用數個數個網站和服務的開發。 隨著 Web 應用程式開發策略的演進，架構能夠逐步發展 ASP.NET MVC 和 ASP.NET Web API等技術。 隨著 Web 應用程式開發進入雲端運算世界， Project Katana 提供一組基礎元件來 ASP.NET 應用程式，讓它們成為彈性、可攜式、輕量型，並提供更佳的效能–讓 Project Katana 雲端能將您的 ASP.NET 應用程式優化。
為何為 Katana – 為何現在？
無論開發人員架構或使用者產品為何，請務必瞭解建立產品的基礎動機，以及瞭解產品建立物件的一部分。 ASP.NET 最初是以兩個客戶為考慮而建立。
第一組客戶是傳統 ASP 開發人員。 此時，ASP 是透過交錯標記和伺服器端腳本來建立動態、資料驅動網站和應用程式的主要技術之一。 ASP 執行時間提供的伺服器端腳本包含一組物件，以抽象化基礎 HTTP 通訊協定和 Web 服務器的核心層面，並提供其他服務的存取權，例如會話和應用程式狀態管理、快取等。雖然功能強大，但傳統 ASP 應用程式在大小和複雜度成長時，成為管理的挑戰。 這主要是因為腳本環境中找不到結構，再加上程式碼和標記交錯所產生的程式碼重複。 為了利用傳統 ASP 的優點，同時解決一些挑戰，ASP.NET 利用.NET Framework物件導向語言所提供的程式碼組織，同時保留傳統 ASP 開發人員習慣使用的伺服器端程式設計模型。
ASP.NET 的第二組目標客戶是 Windows 商務應用程式開發人員。 不同于傳統 ASP 開發人員，他們習慣撰寫 HTML 標籤和程式碼來產生更多 HTML 標籤，WinForms 開發人員 (例如 VB6 開發人員，) 習慣使用包含畫布和一組豐富使用者介面控制項的設計階段體驗。 第一版 ASP.NET – 也稱為「Web Form」提供類似的設計階段體驗，以及使用者介面元件的伺服器端事件模型，以及一組基礎結構功能 (，例如 ViewState) ，以在用戶端和伺服器端程式設計之間建立順暢的開發人員體驗。 Web Form在 WinForms 開發人員熟悉的具狀態事件模型中，有效地隱藏 Web 的無狀態本質。
歷程記錄模型所引發的挑戰
淨結果是成熟、功能豐富的執行時間和開發人員程式設計模型。 不過，這項功能豐富度有一些值得注意的挑戰。 首先，架構是 整合型架構，其邏輯上不同的功能單位會緊密結合在相同的System.Web.dll元件 (例如，具有 Web 表單架構的核心 HTTP 物件) 。 其次，ASP.NET 包含在較大的.NET Framework中，這表示發行之間的時間依年數排序。這讓 ASP.NET 難以跟上在快速演進的 Web 開發中發生的所有變更。 最後，System.Web.dll本身與特定 Web 裝載選項的幾個不同方式結合：Internet Information Services (IIS) 。
進化步驟：ASP.NET MVC 和 ASP.NET Web API
Web 開發中發生許多變更！ Web 應用程式逐漸開發成一系列小型、專注的元件，而不是大型架構。 元件數目，以及發行元件的頻率，會以更快的速率增加。 很明顯地，保持 Web 的步調需要架構變得更小、分離且更專注，而不是更豐富功能，因此 ASP.NET 小組採取數個逐步步驟，讓 ASP.NET 成為一系列可插入式 Web 元件，而不是單一架構。
其中一項早期變更是已知模型檢視控制器 (MVC) 設計模式的熱門程度，因為 Ruby on Rails 之類的 Web 開發架構。 此建置 Web 應用程式的樣式可讓開發人員更充分掌控應用程式的標記，同時仍保留標記和商務邏輯的分隔，這是 ASP.NET 的初始銷售點之一。 為了符合這種 Web 應用程式開發的需求，Microsoft 有機會將MVC 從頻外 (開發 ASP.NET MVC，而不是將其納入.NET Framework) ，讓其更適合未來。 ASP.NET MVC 已發行為獨立下載。 這可讓工程小組更頻繁地提供更新，比先前可能還要多。
Web 應用程式開發的另一個主要轉變是從動態、伺服器產生的網頁移轉至靜態初始標記，以及從用戶端腳本透過 AJAX 要求與後端 Web API通訊之頁面的動態區段。 此架構轉移有助於推動 Web API 的提升，以及 ASP.NET Web API架構的開發。 如同 ASP.NET MVC 的情況，發行 ASP.NET Web API提供另一個機會，進一步發展 ASP.NET 成為更模組化的架構。 工程小組利用機會並建置 ASP.NET Web API，使其與System.Web.dll中找到的任何核心架構類型沒有任何相依性。 這已啟用兩件事：首先，ASP.NET Web API可能會以完全獨立的方式演進 (，而且可能會因為透過 NuGet) 傳遞而繼續快速逐一查看。 其次，因為沒有外部相依性可System.Web.dll，因此沒有 IIS 的相依性，ASP.NET Web API包含在自訂主機 (中執行的功能，例如主控台應用程式、Windows 服務等)
未來：Nimble 架構
藉由將架構元件彼此分離，然後在 NuGet 上發行它們，架構現在可以 更獨立且更快速地逐一查看。 此外，Web API 自我裝載功能的威力和彈性，對想要為其服務提供 小型輕量主機 的開發人員而言非常吸引人。 事實上，它證明其他架構也想要這項功能，而且這在每一個架構在其本身的基底位址上執行于自己的主機進程中，而且需要獨立管理 (啟動、停止等等。) ， 新式 Web 應用程式通常支援靜態檔案服務、動態頁面產生、Web API，以及最近即時/推播通知。 預期每個服務都應該獨立執行和管理，只是不切實際。
需要的是單一裝載抽象概念，可讓開發人員從各種不同的元件和架構撰寫應用程式，然後在支援主機上執行該應用程式。
適用于 .NET 的 Open Web 介面 (OWIN)
受到 Rack 在 Ruby 社群中達成之優點的啟發，.NET 社群的數個成員會設定為在 Web 服務器和架構元件之間建立抽象概念。 OWIN 抽象概念的兩個設計目標是簡單，而且對於其他架構類型需要最少的可能相依性。 這兩個目標有助於確保：
- 新元件更容易開發和取用。
- 應用程式可以在主機與可能整個平臺/作業系統之間更輕鬆地移植。
產生的抽象概念包含兩個核心元素。 第一個是環境字典。 此資料結構負責儲存處理 HTTP 要求和回應所需的所有狀態，以及任何相關的伺服器狀態。 環境字典的定義如下：
IDictionary<string, object>
OWIN 相容的 Web 服務器負責填入環境字典，例如 HTTP 要求和回應的本文資料流程和標頭集合。 然後，應用程式或架構元件會負責以其他值填入或更新字典，並寫入回應本文資料流程。
除了指定環境字典的類型之外，OWIN 規格還會定義核心字典索引鍵值組的清單。 例如，下表顯示 HTTP 要求所需的字典索引鍵：
| 金鑰名稱 | 值描述 |
|---|---|
"owin.RequestBody" |
具有要求本文的 Stream，如果有的話。 如果沒有要求本文，Stream.Null 可以當做預留位置使用。 請參閱 要求本文。 |
"owin.RequestHeaders" |
IDictionary<string, string[]>要求標頭的 。 請參閱 標頭。 |
"owin.RequestMethod" |
， string 包含要求 (的 HTTP 要求方法，例如 、 "GET""POST") 。 |
"owin.RequestPath" |
， string 包含要求路徑。 路徑必須相對於應用程式委派的「根」;請參閱 路徑。 |
"owin.RequestPathBase" |
， string 包含對應至應用程式委派「根」的要求路徑部分;請參閱 路徑。 |
"owin.RequestProtocol" |
， string 包含通訊協定名稱和版本 (例如 "HTTP/1.0" 或 "HTTP/1.1") 。 |
"owin.RequestQueryString" |
， string 包含 HTTP 要求 URI 的查詢字串元件，不含前置 「？」 (例如 "foo=bar&baz=quux") 。 此值可能是空字串。 |
"owin.RequestScheme" |
， string 包含用於要求 (的 URI 配置，例如 、 "http""https") ;請參閱 URI 配置。 |
OWIN 的第二個主要元素是應用程式委派。 這是函式簽章，可作為 OWIN 應用程式中所有元件之間的主要介面。 應用程式委派的定義如下所示：
Func<IDictionary<string, object>, Task>;
然後，應用程式委派只是 Func 委派類型的實作，函式會接受環境字典做為輸入並傳回 Task。 此設計對開發人員有數個影響：
- 為了撰寫 OWIN 元件，需要非常少量的類型相依性。 這可大幅增加 OWIN 對開發人員的協助工具。
- 非同步設計可讓抽象概念有效率地處理運算資源，特別是在更密集的 I/O 作業中。
- 因為應用程式委派是不可部分完成的執行單位，而且因為環境字典是以委派上的參數形式傳送，所以 OWIN 元件可以輕鬆地鏈結在一起，以建立複雜的 HTTP 處理管線。
從實作的觀點來看，OWIN 是 () http://owin.org/html/owin.html 規格。 其目標是不是下一個 Web 架構，而是 Web 架構和網頁伺服器互動方式的規格。
如果您已調查 OWIN 或 Katana，您可能也會注意到 Owin NuGet 套件 和Owin.dll。 此程式庫包含單一介面 [IAppBuilder]/dotnet/api/microsoft.aspnetcore.builder.iapplicationbuilder) ，其會正式化併合並 OWIN 規格 第 4 節 中所述的啟動順序。 雖然不需要建置 OWIN 伺服器，但 [IAppBuilder]/dotnet/api/microsoft.aspnetcore.builder.iapplicationbuilder) 介面提供具體參考點，而且由 Katana 專案元件使用它。
Project Katana
雖然 OWIN 規格和 Owin.dll 都是社群擁有，而且社群會執行開放原始碼工作， 但 Katana 專案代表一組仍為開放原始碼的 OWIN 元件，由 Microsoft 建置和發行。 這些元件包括基礎結構元件，例如主機和伺服器，以及功能元件，例如驗證元件和SignalR和 ASP.NET Web API等架構的系結。 專案具有下列三個高階目標：
- 可攜式 – 元件應該能夠輕易地取代新的元件，因為它們可供使用。 這包括從架構到伺服器和主機的所有元件類型。 此目標的影響在於協力廠商架構可以在 Microsoft 伺服器上順暢地執行，而 Microsoft 架構可能會在協力廠商伺服器和主機上執行。
- 模組化/彈性– 不同于許多架構，其中包含依預設開啟的眾多功能，因此，Katana 專案元件應該很小且專注，可控制應用程式開發人員判斷應用程式中要使用的元件。
- 輕量型/高效能/可調整 – 藉由將架構的傳統概念分成一組由應用程式開發人員明確新增的小型焦點元件，產生的 Katana 應用程式可能會耗用較少的運算資源，因此，處理更多負載，而不是使用其他類型的伺服器和架構。 隨著應用程式的需求需要基礎基礎結構中的更多功能，這些功能可以新增至 OWIN 管線，但這應該是應用程式開發人員的明確決策。 此外，較低層級元件的替代性表示當它們可供使用時，可以順暢地引進新的高效能伺服器來改善 OWIN 應用程式的效能，而不會中斷這些應用程式。
開始使用 Katana 元件
第一次引進時， Node.js架構的 其中一個層面會立即吸引人注意，就是可以撰寫和執行網頁伺服器的簡單性。 如果 Katana 目標是以 Node.js為基礎來框架，則其中一個目標可能會摘要說明，其中一個目標可能是讓 Node.js(和 架構) 的許多優點，而不需要強制開發人員擲回她對於開發 ASP.NET Web 應用程式所知道的所有專案。 若要讓此語句保持 true，開始使用 Katana 專案本質上應該同樣簡單， 才能Node.js。
建立 「Hello World！」
JavaScript 與 .NET 開發之間的一個顯著差異是編譯器存在 (或缺少) 。 因此，簡單 Katana 伺服器的起點是 Visual Studio 專案。 不過，我們可以從最基本的專案類型開始：空白 ASP.NET Web 應用程式。
接下來，我們會將 Microsoft.Owin.Host.SystemWeb NuGet 套件安裝到專案中。 此套件提供在 ASP.NET 要求管線中執行的 OWIN 伺服器。 您可以在 NuGet 資源庫 找到它，而且可以使用 Visual Studio 套件管理員對話方塊或套件管理員主控台搭配下列命令安裝：
install-package Microsoft.Owin.Host.SystemWeb
安裝 Microsoft.Owin.Host.SystemWeb 套件會將一些額外的套件安裝為相依性。 其中一個相依性是 Microsoft.Owin ，一個程式庫提供數種協助程式類型和方法來開發 OWIN 應用程式。 我們可以使用這些類型快速撰寫下列 「hello world」 伺服器。
public class Startup
{
public void Configuration(IAppBuilder app)
{
app.Run(context =>
{
context.Response.ContentType = "text/plain";
return context.Response.WriteAsync("Hello World!");
});
}
}
這個非常簡單的 Web 服務器現在可以使用 Visual Studio 的 F5 命令來執行，並包含偵錯的完整支援。
切換主機
根據預設，先前的 「hello world」 範例會在 ASP.NET 要求管線中執行，它會在 IIS 的內容中使用 System.Web。 這可以自行增加極大的價值，因為它可讓我們受益于具有 IIS 管理功能和整體成熟度之 OWIN 管線的彈性和組合性。 不過，在某些情況下，IIS 所提供的優點並非必要，而且需要較小的輕量型主機。 然後，若要在 IIS 和 System.Web 之外執行簡單的 Web 服務器，需要什麼？
為了說明可攜性目標，從 Web 服務器主機移至命令列主機只需要將新的伺服器和主機相依性新增至專案的輸出檔案夾，然後啟動主機。 在此範例中，我們會將 Web 服務器裝載在名為 OwinHost.exe 的 Katana 主機中，並使用以 Katana HttpListener 為基礎的伺服器。 與其他 Katana 元件類似，這些元件會使用下列命令從 NuGet 取得：
install-package OwinHost
接著，我們可以從命令列流覽至專案根資料夾，並直接執行 OwinHost.exe 安裝在其個別 NuGet 套件的工具資料夾中) (。 根據預設， OwinHost.exe 會設定為尋找以 HttpListener 為基礎的伺服器，因此不需要其他設定。 在網頁瀏覽器中流覽以顯示 http://localhost:5000/ 應用程式現在透過主控台執行。
Katana 架構
Katana 元件架構會將應用程式分成四個邏輯層，如下所示： 主機、伺服器、中介軟體 和 應用程式。 元件架構會以這類方式來考慮，在許多情況下，可以輕鬆地取代這些層的實作，而不需要重新編譯應用程式。
主機
主機負責：
管理基礎程式。
協調工作流程，以選取伺服器並建構 OWIN 管線，以便處理要求。
目前，有 3 個主要裝載選項適用于以 Katana 為基礎的應用程式：
IIS/ASP.NET：使用標準 HttpModule 和 HttpHandler 類型，OWIN 管線可以在 IIS 上執行，作為 ASP.NET 要求流程的一部分。 ASP.NET 裝載支援，方法是將 Microsoft.AspNet.Host.SystemWeb NuGet 套件安裝到 Web 應用程式專案中。 此外，因為 IIS 同時做為主機和伺服器，所以 OWIN 伺服器/主機區別會在此 NuGet 套件中合併，這表示如果使用 SystemWeb 主機，開發人員就無法替代替代伺服器實作。
自訂主機：Kaatana 元件套件可讓開發人員在自己的自訂程式中裝載應用程式，無論是主控台應用程式、Windows 服務等等。這項功能看起來類似于 Web API 所提供的自我裝載功能。 下列範例顯示 Web API 程式碼的自訂主機：
static void Main()
{
var baseAddress = new Uri("http://localhost:5000");
var config = new HttpSelfHostConfiguration(baseAddress);
config.Routes.MapHttpRoute("default", "{controller}");
using (var svr = new HttpSelfHostServer(config))
{
svr.OpenAsync().Wait();
Console.WriteLine("Press Enter to quit.");
Console.ReadLine();
}
}
適用于 Katana 應用程式的自我主機設定類似：
static void Main(string[] args)
{
const string baseUrl = "http://localhost:5000/";
using (WebApplication.Start<Startup>(new StartOptions { Url = baseUrl }))
{
Console.WriteLine("Press Enter to quit.");
Console.ReadKey();
}
}
Web API 與 Katana 自我裝載範例之間的一個顯著差異是 Web API 組態程式碼遺漏了來自 Katana 自我主機範例。 為了同時啟用可攜性和可撰寫性，Katana 會將啟動伺服器的程式碼與設定要求處理管線的程式碼分開。 接著，設定 Web API 的程式碼會包含在 Startup 類別中，此類別會另外指定為 WebApplication.Start 中的類型參數。
public class Startup
{
public void Configuration(IAppBuilder app)
{
var config = new HttpConfiguration();
config.Routes.MapHttpRoute("default", "{controller}");
app.UseWebApi(config);
}
}
本文稍後將更詳細地討論啟動類別。 不過，啟動 Katana 自我裝載程式所需的程式碼看起來非常類似您在 ASP.NET Web API自我裝載應用程式中可能目前使用的程式碼。
OwinHost.exe：雖然有些想要撰寫自訂程式來執行 Katana Web 應用程式，但許多都想要只啟動預先建置的可執行檔，以啟動伺服器並執行其應用程式。 在此案例中，Katana 元件套件包含 OwinHost.exe 。 從專案的根目錄內執行時，此可執行檔會啟動伺服器， (它預設會使用 HttpListener 伺服器) ，並使用慣例來尋找和執行使用者的啟動類別。 如需更細微的控制，可執行檔會提供一些額外的命令列參數。
伺服器
雖然主機負責啟動和維護應用程式執行的程式，但伺服器的責任是開啟網路通訊端、接聽要求，並透過 (使用者指定的 OWIN 元件管線傳送，因為您可能已經注意到，應用程式開發人員的 Startup 類別會指定此管線) 。 目前，Katana 專案包含兩個伺服器實作：
- Microsoft.Owin.Host.SystemWeb：如先前所述，IIS 與 ASP.NET 管線同時做為主機和伺服器。 因此，當選擇此裝載選項時，IIS 都會管理主機層級的考慮，例如進程啟用和接聽 HTTP 要求。 針對 ASP.NET Web 應用程式，接著會將要求傳送至 ASP.NET 管線。 Katana SystemWeb 主機會註冊 ASP.NET HttpModule 和 HttpHandler，以攔截流經 HTTP 管線的要求，並透過使用者指定的 OWIN 管線傳送要求。
- Microsoft.Owin.Host.HttpListener：如其名稱所示，此 Katana 伺服器會使用.NET Framework的 HttpListener 類別來開啟通訊端，並將要求傳送至開發人員指定的 OWIN 管線。 這目前是 Katana 自我裝載 API 和OwinHost.exe的預設伺服器選擇。
中介軟體/架構
如先前所述，當伺服器接受來自用戶端的要求時，它會負責透過開發人員啟動程式碼所指定的 OWIN 元件的管線傳遞它。 這些管線元件稱為中介軟體。
在非常基本層級，OWIN 中介軟體元件只需要實作 OWIN 應用程式委派，才能呼叫它。
Func<IDictionary<string, object>, Task>
不過，為了簡化中介軟體元件的開發和組合，Katana 支援少數中介軟體元件的慣例和協助程式類型。 最常見的是 OwinMiddleware 類別。 使用這個類別所建置的自訂中介軟體元件看起來會類似下列內容：
public class LoggerMiddleware : OwinMiddleware
{
private readonly ILog _logger;
public LoggerMiddleware(OwinMiddleware next, ILog logger) : base(next)
{
_logger = logger;
}
public override async Task Invoke(IOwinContext context)
{
_logger.LogInfo("Middleware begin");
await this.Next.Invoke(context);
_logger.LogInfo("Middleware end");
}
}
這個類別衍生自 OwinMiddleware ，實作建構函式，該建構函式會接受管線中下一個中介軟體的實例做為其引數之一，然後將它傳遞至基底建構函式。 用來設定中介軟體的其他引數也會在下一個中介軟體參數之後宣告為建構函式參數。
在執行時間，中介軟體會透過覆寫 Invoke 的 方法來執行。 這個方法會採用 類型的 OwinContext 單一引數。 此內容物件是由 Microsoft.Owin 稍早所述的 NuGet 套件提供，並提供對要求、回應和環境字典的強型別存取，以及一些額外的協助程式類型。
中介軟體類別可以輕鬆地新增至應用程式啟動程式碼中的 OWIN 管線，如下所示：
public class Startup
{
public void Configuration(IAppBuilder app)
{
app.Use<LoggerMiddleware>(new TraceLogger());
}
}
由於 Sapana 基礎結構只會建置 OWIN 中介軟體元件的管線，而且因為元件只需要支援應用程式委派才能參與管線，中介軟體元件可以範圍從簡單的記錄器到整個架構，例如 ASP.NET、Web API 或 SignalR。 例如，將 ASP.NET Web API新增至先前的 OWIN 管線需要新增下列啟動程式碼：
public class Startup
{
public void Configuration(IAppBuilder app)
{
app.Use<LoggerMiddleware>(new TraceLogger());
var config = new HttpConfiguration();
// configure Web API
app.UseWebApi(config);
// additional middleware registrations
}
}
Sapana 基礎結構會根據在 Configuration 方法中新增至 IAppBuilder 物件的順序，建置中介軟體元件的管線。 在我們的範例中，LoggerMiddleware 可以處理流經管線的所有要求，不論這些要求最終如何處理。 這可讓中介軟體元件 (例如驗證元件) 可以處理管線的要求，這些管線包含多個元件和架構 (例如 ASP.NET Web API、SignalR 和靜態檔案伺服器) 。
應用程式
如先前範例所說明，OWIN 和 Katana 專案不應視為新的應用程式程式設計模型，而是將應用程式程式設計模型和架構與伺服器和裝載基礎結構分離的抽象概念。 例如，建置 Web API 應用程式時，開發人員架構會繼續使用 ASP.NET Web API 架構，不論應用程式是否使用來自 Katana 專案的元件在 OWIN 管線中執行。 應用程式開發人員可以看到 OWIN 相關程式碼的其中一個位置是應用程式啟動程式碼，其中開發人員會撰寫 OWIN 管線。 在啟動程式碼中，開發人員會註冊一系列的 UseXx 語句，通常是每個處理傳入要求的中介軟體元件。 此體驗與在目前 System.Web 世界中註冊 HTTP 模組的效果相同。 一般而言，較大的架構中介軟體，例如 ASP.NET Web API或SignalR會在管線結章節附註冊。 跨領域中介軟體元件，例如用於驗證或快取的元件，通常會註冊到管線的開頭，以便處理稍後在管線中註冊的所有架構和元件要求。 這會將中介軟體元件彼此分開，以及與基礎結構元件分開，可讓元件以不同的速度演進，同時確保整體系統維持穩定。
元件 – NuGet 套件
就像許多目前的程式庫和架構一樣，Katana 專案元件會以一組 NuGet 套件的形式傳遞。 針對即將推出的 2.0 版，Katana 套件相依性圖表如下所示。 (按一下影像以取得較大的檢視。)
幾乎每一個在 Katana 專案中的套件都取決於 Owin 套件，直接或間接相依。 您可能會記得，這是包含 IAppBuilder 介面的套件，它提供 OWIN 規格第 4 節中所述之應用程式啟動順序的具體實作。 此外，許多套件都相依于 Microsoft.Owin，其提供一組協助程式類型來處理 HTTP 要求和回應。 封裝的其餘部分可以分類為裝載基礎結構套件 (伺服器或主機) 或中介軟體。 在 Katana 專案外部的套件和相依性會顯示在橘色中。
Katana 2.0 的裝載基礎結構包括 SystemWeb 和 HttpListener 型伺服器、使用 OwinHost.exe 執行 OWIN 應用程式的 OwinHost 套件，以及自訂主機中用於自我裝載 OWIN 應用程式的 Microsoft.Owin.Hosting 套件 (，例如主控台應用程式、Windows 服務等)
針對 Katana 2.0，中介軟體元件主要著重于提供不同的驗證方式。 提供診斷的一個額外中介軟體元件，可支援啟動和錯誤頁面。 隨著 OWIN 成長到事實上的裝載抽象概念，由 Microsoft 和協力廠商開發的中介軟體元件生態系統也會成長。
結論
從頭開始，Katana 專案的目標尚未建立，因而強制開發人員學習另一個 Web 架構。 相反地，目標是要建立抽象概念，讓 .NET Web 應用程式開發人員比先前更容易選擇。 藉由將一般 Web 應用程式堆疊的邏輯層分成一組可取代的元件，Katana 專案可讓整個堆疊中的元件以任何對這些元件有意義的速率來改善。 透過在簡單 OWIN 抽象概念周圍建置所有元件，Katana 可讓架構和建置在它們之上的應用程式在各種不同伺服器和主機之間可移植。 藉由讓開發人員控制堆疊，Katana 可確保開發人員能夠最終選擇輕量型或功能豐富的 Web 堆疊。
如需有關 Katana 的詳細資訊
- GitHub 上的 Katana 專案： https://github.com/aspnet/AspNetKatana/ 。
- 影片：Howard Dierking 所 ASP.NET 的 Katana 專案 - OWIN。
通知
- Rick Anderson： (twitter @RickAndMSFT ) Rick 是 Microsoft 資深程式設計作者，著重于 Azure 和 MVC。
- Scott Hanselman： (twitter @shanselman )
- JonGaloway： (twitter @jongalloway )
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應