<轉>下一代Asp.net開發規範OWIN（1）—— OWIN產生的背景以及簡單介紹

標籤：des   winform   style   blog   http   color   os   io   使用   

2014-09-04 07:22 by JustRun

http://www.cnblogs.com/JustRun1983/p/3955238.html

 

隨著VS2013的發布，微軟在Asp.Net中引入了很多新的特性，比如使用新的許可權驗證模組Identity,使用Async來提高Web伺服器的輸送量和效率等。其中一個不得不提的是OWIN和Katana. OWIN的全稱是Open Web Interface For .Net, OWIN是.Net開源社區借鑒Ruby而制定的.Net Web開發架構，有著非常簡單的規範定義，同時極度降低了模組間耦合。OWIN並不是一個具體的實現，而只是一個規範，用來指導如何構建一個符合OWIN標準的Web生態環境。微軟引入並推廣OWIN，同時依照OWIN規範，實現了Katana。

可以這麼說，OWIN將會使Asp.net煥發第二春。下面，就讓我們一步一步走近OWIN和Katana，一睹芳容。

閱讀目錄:

一. 回顧Asp.net的發展曆史

二. 解決問題的思路

三. OWIN介紹

四，OWIN前景以及預測

一， 回顧Asp.net的發展曆史

不知不覺，Asp.net已經伴隨我們了10多個年頭，漸漸步入中年。面對日新月異的Web開發變革，Asp.net已經顯得有些力不從心。為什麼會出現這種情況，讓我們來回顧一下Asp.net的發展曆史:

Asp階段

最初開發Web，使用的是Asp, 這是一種嵌入在頁面中的指令碼語言。Asp的優勢是簡單，上手快，但是隨著開發的日益複雜和Web程式的不斷龐大，Asp這種邏輯代碼和頁面Html混在一起的開發方式已經不能夠適應了。

Asp.net Web Form階段

由於Asp的短板，升級Asp，打造一個新的Web開發平台已經是必然的事情了。猜想微軟可能想讓Winform上的開發人員方便地遷移到Web開發上來，於是打造了一個開發過程和Winform及其類似的開發方式，這就是Asp.Net.

Asp.net Web Form在當時無疑是先進的，但是隨著時間的推移，它的一些問題也暴露出來:
Asp.net中大部分的核心類都包含在System.Web.dll中，而System.Web.dll是包含在.Net Framework中的，這就意味著如果要發布一個新版本的Asp.net必須伴隨著新的.Net Framework一起發布，這導致了Asp.net更新頻率降低。另外，System.Web.dll是和IIS耦合的，使得Asp.net程式無法遷移到其它伺服器上。

積極的改變

新的Asp.net MVC改變了過去的缺點，它是作為獨立於.Net Framework發布的。所以MVC的版本變化，是無需受制於.Net Framework. 開發MVC的項目組就可以自主的快速開發和發布新的版本的MVC.
更進一步，在開發和發布Web API的時候，甚至都沒有用到任何包含在System.Web.dll中的類型，這意味著:

• Web API完全是無外部依賴的，它通過Nuget快速的發布和更新。
• 不依賴於System.Web.dll, 也就意味著不依賴於IIS的服務，所以Web API是可以運行在其它宿主進程中的, 比如控制台程式，windows service等。

未來:更加靈活的架構

通過解構Asp.net開發中的一個一個架構組件，微軟就能夠更加快速的迭代和通過Nuget發布新的版本，添加新的增強功能。
未來更加靈活的架構就是我們可以隨意根據項目需要，組合這些組件，然後運行在支援的Host上。

二，解決問題的思路

在引入OWIN之前，我們來對Web請求到響應的過程進行抽象:
一個Web請求的全過程是一個簡單的輸入和輸出， 輸入是request包含的頭資訊、cookie、資料等資訊，輸出是最後的Html. 這就好像是放進去麵粉，最後出來的是做好的饅頭。但是從麵粉變成饅頭卻要經曆很多工序，這一道一道的工序，就組成了整個流程。非常類似於裝飾者模式，每一個裝飾者對象都遵循同樣的介面，這樣我們就可以將不同的裝飾者拼接起來。

是借鑒的python中的WSGI規範(Python Web Server Gateway Interface)， 和下面將講到的OWIN基本類似. Request經過一層層的洋蔥皮，最後輸出。這一層一層的洋蔥皮就是我們的符合OWIN規範的組件。

三，OWIN介紹

OWIN就是按照上面思路和目標制定的一個規範，不包含任何具體實現。其目的是在web伺服器和應用程式之間隔離出一個抽象層，使它們之間解耦。
OWIN設計的2個目標:  簡單，以及盡量少的依賴其它的架構類型。
這樣就能夠:

• 新的組件能夠非常簡單的開發和應用
• 程式能夠簡便地在host和OS上遷移

OWIN核心定義

OWIN將web應用中的request, response, session, cookie等所有相關資訊都簡化成下面的字典。本質上來說，這個字典就包含了一個web請求的所有上下文資訊。
一個符合OWIN的web伺服器，需要將請求資訊封裝成下面的字典類型，傳遞到下一層中。而下一層的組件或者應用程式，所要做的就是讀取，修改這個字典的資料。最後，Web伺服器得到這個層層處理過的字典，然後輸出網頁到用戶端

IDictionary<string, object>
下面是具體的定義

Key Name	Value Description
"owin.RequestBody"	A Stream with the request body, if any. Stream.Null MAY be used as a placeholder if there is no request body. See Request Body.
"owin.RequestHeaders"	An IDictionary<string, string[]><string, string[]=""> of request headers. See Headers.
"owin.RequestMethod"	A string containing the HTTP request method of the request (e.g., "GET", "POST").
"owin.RequestPath"	A string containing the request path. The path MUST be relative to the "root" of the application delegate; see Paths.
"owin.RequestPathBase"	A string containing the portion of the request path corresponding to the "root" of the application delegate; see Paths.
"owin.RequestProtocol"	A string containing the protocol name and version (e.g. "HTTP/1.0" or "HTTP/1.1").
"owin.RequestQueryString"	A string containing the query string component of the HTTP request URI, without the leading “?” (e.g., "foo=bar&baz=quux"). The value may be an empty string.
"owin.RequestScheme"	A string containing the URI scheme used for the request (e.g., "http", "https"); see URI Scheme.

另外一個核心是application delegate，這是所有運行在OWIN協議下的組件都需要遵循的介面

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

這樣定義的原因是: 

• 由於依賴少，寫一個component非常容易和簡單
• 非同步設計使得程式的運行效率更高，特別是在遇到一些I/O密集的操作時
• application delegate 是可執行檔最小單元，OWIN components可以非常容易的互相串連組成一個Http處理管道

四，OWIN前景以及預測

由於使用OWIN規範，使得Asp.net進化的更加快，對於新的東西也能夠快速響應。

OWIN的發展，將來會有越來越多的基於OWIN的應用程式框架出現（中介軟體），也將會由更多的OwinHost出現，其一就是微軟先發制人Katana，它能夠運行於Windows中，獨立於IIS為支援OWIN協議的架構提供宿主支援；而另外一款則是率先支援OWIN協議的運行於Linux以及FreeBSD的Jexus Web Server（需要Jexus 5.6 以上版本）.

儘管Asp.Net年紀很大，但是現在也越來越潮了，小夥子們有的東西，它也有了，而且以後對時尚的敏感度會更加敏銳。而它所具有的穩定，成熟氣質，卻是其它小夥子難以具備的。這是.Net最好的時代，不是嗎?

<轉>下一代Asp.net開發規範OWIN（1）—— OWIN產生的背景以及簡單介紹