OWIN產(chǎn)生的背景以及簡單介紹
隨著VS2013的發(fā)布，微軟在Asp.Net中引入了很多新的特性，比如使用新的權(quán)限驗證模塊Identity, 使用Async來提高Web服務(wù)器的吞吐量和效率等。其中一個不得不提的是OWIN和Katana. OWIN的全稱是Open Web Interface For .Net, OWIN是.Net開源社區(qū)借鑒Ruby而制定的.Net Web開發(fā)架構(gòu)，有著非常簡單的規(guī)范定義，同時極度降低了模塊間耦合。OWIN并不是一個具體的實現(xiàn)，而只是一個規(guī)范，用來指導(dǎo)如何構(gòu)建一個符合OWIN標(biāo)準(zhǔn)的Web生態(tài)環(huán)境。微軟引入并推廣OWIN，同時依照OWIN規(guī)范，實現(xiàn)了Katana。
可以這么說，OWIN將會使Asp.net煥發(fā)第二春。下面，就讓我們一步一步走近OWIN和Katana，一睹芳容。
閱讀目錄:
一. 回顧Asp.net的發(fā)展歷史
二. 解決問題的思路
三. OWIN介紹
四，OWIN前景以及預(yù)測
一， 回顧Asp.net的發(fā)展歷史
不知不覺，Asp.net已經(jīng)伴隨我們了10多個年頭，漸漸步入中年。面對日新月異的Web開發(fā)變革，Asp.net已經(jīng)顯得有些力不從心。為什么會出現(xiàn)這種情況，讓我們來回顧一下Asp.net的發(fā)展歷史:
Asp階段
最初開發(fā)Web，使用的是Asp, 這是一種嵌入在頁面中的腳本語言。Asp的優(yōu)勢是簡單，上手快，但是隨著開發(fā)的日益復(fù)雜和Web程序的不斷龐大，Asp這種邏輯代碼和頁面Html混在一起的開發(fā)方式已經(jīng)不能夠適應(yīng)了。
Asp.net Web Form階段
由于Asp的短板，升級Asp，打造一個新的Web開發(fā)平臺已經(jīng)是必然的事情了。猜想微軟可能想讓W(xué)inform上的開發(fā)者方便地遷移到Web開發(fā)上來，于是打造了一個開發(fā)過程和Winform及其類似的開發(fā)方式，這就是Asp.Net.
Asp.net Web Form在當(dāng)時無疑是先進(jìn)的，但是隨著時間的推移，它的一些問題也暴露出來:
Asp.net中大部分的核心類都包含在System.Web.dll中，而System.Web.dll是包含在.Net Framework中的，這就意味著如果要發(fā)布一個新版本的Asp.net必須伴隨著新的.Net Framework一起發(fā)布，這導(dǎo)致了Asp.net更新頻率降低。另外，System.Web.dll是和IIS耦合的，使得Asp.net程序無法遷移到其它服務(wù)器上。
積極的改變
新的Asp.net MVC改變了過去的缺點(diǎn)，它是作為獨(dú)立于.Net Framework發(fā)布的。所以MVC的版本變化，是無需受制于.Net Framework. 開發(fā)MVC的項目組就可以自主的快速開發(fā)和發(fā)布新的版本的MVC.
更進(jìn)一步，在開發(fā)和發(fā)布Web API的時候，甚至都沒有用到任何包含在System.Web.dll中的類型，這意味著:
- Web API完全是無外部依賴的，它通過Nuget快速的發(fā)布和更新。
- 不依賴于System.Web.dll, 也就意味著不依賴于IIS的服務(wù)，所以Web API是可以運(yùn)行在其它宿主進(jìn)程中的, 比如控制臺程序，windows service等。
未來:更加靈活的框架
通過解構(gòu)Asp.net開發(fā)中的一個一個框架組件，微軟就能夠更加快速的迭代和通過Nuget發(fā)布新的版本，添加新的增強(qiáng)功能。
未來更加靈活的框架就是我們可以隨意根據(jù)項目需要，組合這些組件，然后運(yùn)行在支持的Host上。
二，解決問題的思路
在引入OWIN之前，我們來對Web請求到響應(yīng)的過程進(jìn)行
抽象
:
一個Web請求的全過程是一個簡單的輸入和輸出， 輸入是request包含的頭信息、cookie、數(shù)據(jù)等信息，輸出是最后的Html. 這就好像是放進(jìn)去面粉，最后出來的是做好的饅頭。但是從面粉變成饅頭卻要經(jīng)歷很多工序，這一道一道的工序，就組成了整個流程。非常類似于裝飾者模式，每一個裝飾者對象都遵循同樣的接口，這樣我們就可以將不同的裝飾者拼接起來。
下圖是借鑒的python中的WSGI規(guī)范(Python Web Server Gateway Interface)， 和下面將講到的OWIN基本類似. Request經(jīng)過一層層的洋蔥皮，最后輸出。這一層一層的洋蔥皮就是我們的符合OWIN規(guī)范的組件。
?
三，OWIN介紹
OWIN就是按照上面思路和目標(biāo)制定的一個規(guī)范，不包含任何具體實現(xiàn)
。其目的是在web服務(wù)器和應(yīng)用程序之間隔離出一個抽象層，使它們之間解耦。
OWIN設(shè)計的2個目標(biāo):? 簡單，以及盡量少的依賴其它的框架類型。
這樣就能夠:
- 新的組件能夠非常簡單的開發(fā)和應(yīng)用
- 程序能夠簡便地在host和OS上遷移
OWIN核心定義
OWIN將web應(yīng)用中的request, response, session, cookie等所有相關(guān)信息都簡化成下面的字典
。本質(zhì)上來說，這個字典就包含了一個web請求的所有上下文信息。
一個符合OWIN的web服務(wù)器，需要將請求信息包裝成下面的字典類型，傳遞到下一層中。而下一層的組件或者應(yīng)用程序，所要做的就是讀取，修改這個字典的數(shù)據(jù)。最后，Web服務(wù)器得到這個層層處理過的字典，然后輸出網(wǎng)頁到客戶端
IDictionary<string, object>
下面是具體的定義
|
|
Value Description |
|
|
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 . |
|
|
An?
|
|
|
A?
|
|
|
A?
|
|
|
A?
|
|
|
A?
|
|
|
A?
|
|
|
A?
|
另外一個核心是application delegate ，這是所有運(yùn)行在OWIN協(xié)議下的組件都需要遵循的接口
Func<IDictionary<string, object>, Task>;
這樣定義的原因是:?
- 由于依賴少，寫一個component非常容易和簡單
- 異步設(shè)計使得程序的運(yùn)行效率更高，特別是在遇到一些I/O密集的操作時
- application delegate 是可執(zhí)行的最小單元，OWIN components可以非常容易的互相連接組成一個Http處理管道
四，OWIN前景以及預(yù)測
由于使用OWIN規(guī)范，使得Asp.net進(jìn)化的更加快，對于新的東西也能夠快速響應(yīng)。
OWIN的發(fā)展，將來會有越來越多的基于OWIN的應(yīng)用框架出現(xiàn)（中間件），也將會由更多的OwinHost出現(xiàn)，其一就是微軟先發(fā)制人Katana，它能夠運(yùn)行于Windows中，獨(dú)立于IIS為支持OWIN協(xié)議的框架提供宿主支持；而另外一款則是率先支持OWIN協(xié)議的運(yùn)行于Linux以及FreeBSD的Jexus Web Server（需要Jexus 5.6 以上版本）.
盡管Asp.Net年紀(jì)很大，但是現(xiàn)在也越來越潮了，小伙子們有的東西，它也有了，而且以后對時尚的敏感度會更加敏銳。而它所具有的穩(wěn)定，成熟氣質(zhì)，卻是其它小伙子難以具備的。這是.Net最好的時代，不是嗎?
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯(lián)系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點(diǎn)擊下面給點(diǎn)支持吧，站長非常感激您！手機(jī)微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點(diǎn)擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
