Katana項目為ASP.NET應用程序提供了一組基礎組件，使其能夠靈活，便攜，輕量化，並提供更好的性能 。

為什麽會有Katana

無論是討論開發者框架還是最終用戶產品，重要的是要了解創建產品的基本動機 - 其中的一部分包括知道產品是為誰創建的。ASP.NET最初是為兩類客戶創建的。

第一類客戶是經典的ASP開發人員。當時，ASP是通過交織標記和服務器端腳本動態創建數據驅動的網站和應用程序的主要技術之一。ASP運行時提供的服務器端腳本具有一組抽象基礎HTTP協議和Web服務器的核心方面的對象，並提供對其他服務（如會話和應用程序狀態管理，緩存等）的訪問。雖然經典的ASP應用程序功能強大，但隨著規模和復雜程度的增長而面臨挑戰。這主要是由於在腳本環境中結構不足以發現和標記代碼的交錯產生的代碼重復。

ASP.NET的第二組目標客戶是Windows業務應用程序開發人員。與傳統ASP開發人員不同的是，他們習慣於編寫HTML標記和代碼來生成更多的HTML標記，WinForms開發人員（或之前的VB6開發人員）習慣了實時設計體驗，包括畫布和豐富的用戶界面控件。ASP.NET的第一個版本 - 也被稱為“WebForm”，為用戶界面組件和一組基礎架構功能（如ViewState）提供了類似的實時設計體驗以及服務器端事件模型，以創建無縫的開發人員體驗在客戶端和服務器端編程之間。Web窗體在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組件而不是單個框架。

早期的變化之一是由於諸如Ruby on Rails之類的Web開發框架，眾所周知的模型視圖 - 控制器（MVC）設計模式的受歡迎程度日益提高。這種構建Web應用程序的風格使開發人員更好地控制了應用程序的標記，同時仍保留了標記和業務邏輯的分離，這是ASP.NET的首要賣點之一。為了滿足這種風格的Web應用程序開發的需求，微軟通過開發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服務等） ）

未來：靈活的框架

通過將框架組件彼此解耦，然後在NuGet上發布它們，框架現在可以更獨立更快地進行叠代。此外，Web API自主托管功能的強大功能和靈活性對於想要一個輕量級小型主機的開發人員來說非常有吸引力為他們的服務。事實證明，其他框架也希望能夠實現這一功能，而且這個框架也出現了一個新的挑戰，每個框架都在自己的主機進程中運行，並且需要被管理（啟動，停止等）獨立。現代Web應用程序通常支持靜態文件服務，動態頁面生成，Web API以及最近的實時/推送通知。期望這些服務應該獨立運行和管理是不現實的。

需要的是一個單一的托管抽象，這將使開發人員能夠從各種不同的組件和框架中組合應用程序，然後在支持的主機上運行該應用程序。

開放式Web Interface for .NET（OWIN）

受到Rack在Ruby社區中取得的好處的啟發，.NET社區的幾個成員開始在Web服務器和框架組件之間創建抽象。OWIN抽象的兩個設計目標是簡單，並且對其他框架類型采用最少可能的依賴關系。這兩個目標有助於確保：

• 新組件可以更容易地開發和使用。
• 應用程序可以更容易地在主機和潛在的整個平臺/操作系統之間移植。

最終的抽象由兩個核心元素組成。第一個是環境字典。該數據結構負責存儲處理HTTP請求和響應以及任何相關服務器狀態所需的所有狀態。環境字典定義如下：

IDictionary<string, object>

OWIN兼容的Web服務器負責使用諸如身體流和頭部集合之類的數據來填充環境字典以用於HTTP請求和響應。應用程序或框架組件的責任就是使用附加值填充或更新字典，並寫入響應主體流。

除了指定環境字典的類型外，OWIN規範還定義了核心字典鍵值對的列表。例如，下表顯示了HTTP請求所需的字典鍵：

OWIN的第二個關鍵因素是應用程序委托。這是一個功能簽名，用作OWIN應用程序中所有組件之間的主界面。應用程序委托的定義如下：

Func<IDictionary<string, object>, Task>;

然後，應用程序委托只是Func委托類型的一個實現，該函數接受環境字典作為輸入並返回一個任務。這種設計對開發人員有幾個影響：

• 為了編寫OWIN組件，需要很少的類型依賴關系。這大大增加了OWIN對開發人員的可訪問性。
• 異步設計使得抽象能夠有效地處理計算資源，特別是在更多的I / O密集型操作中。
• 因為應用程序委托是執行的原子單元，並且由於環境字典作為委托的參數攜帶，所以OWIN組件可以輕松鏈接在一起以創建復雜的HTTP處理流水線。

從實現的角度來看，OWIN是一個規範（http://owin.org/html/owin.html）。其目標不是下一個Web框架，而是Web框架和Web服務器交互的規範。

如果您調查過OWIN或Katana，您可能還註意到Owin NuGet軟件包和Owin.dll。該庫包含一個單一的接口，IAppBuilder，它將OWIN規範第4部分描述的啟動順序進行形式化和編碼。雖然為了構建OWIN服務器不是必需的，IAppBuilder接口提供了具體的參考點，由Katana項目組件使用。

Katana項目

而OWIN規範和Owin.dll都是社區所有和社區運行的開源工作，Katana項目代表了一組OWIN組件，雖然仍然是開放源代碼，由Microsoft構建和發布。這些組件包括基礎架構組件（如主機和服務器）以及功能組件，例如身份驗證組件和綁定到框架（如SignalR和ASP.NET Web API）。該項目有以下三個高水平目標：

• 便攜式 - 組件應該能夠輕松地替代新組件，因為它們可用。這包括所有類型的組件，從框架到服務器和主機。這個目標的含義是，第三方框架可以在Microsoft服務器上無縫運行，而Microsoft框架可能會在第三方服務器和主機上運行。
• 模塊化/靈活 - 與許多框架不同，許多框架默認啟用了許多功能，Katana項目組件應該小巧，集中，可以控制應用程序開發人員確定在其應用程序中使用哪些組件。
• 輕量級/性能/可擴展性 - 通過將框架的傳統概念打破為由應用程序開發人員明確添加的一組小型，集中的組件，由此產生的Katana應用程序可以消耗更少的計算資源，從而處理更多的負載，比其他類型的服務器和框架。由於應用程序的要求需要基礎架構的更多功能，因此可以將這些功能添加到OWIN管道中，但這應該是應用程序開發人員的明確決定。此外，較低級別組件的可替代性意味著隨著可用性的升高，新的高性能服務器可以無縫引入，以改善OWIN應用程序的性能，而不會破壞這些應用程序。

Katana的起源