Asp.net MVC項目的部署（二）：對IIS7的補充

06-10

由於第一篇太長，本來應該放在第一篇的關於IIS7的知識被放在了第二篇，你可以結合第一篇，比較著IIS6來理解IIS7的改變。主要參考資料：Pro Asp.net MVC Framework.pdf（你可以搜索下載到）

在IIS7的集成管線模式中請求是如何被處理的

IIS7引入了一個激進的不同以前的管線模式，叫做集成管線模式，在這個模式中.NET是Web伺服器本地支持的一部分。現在，IIS不再需要一個ISAPI擴展來激活.NET代碼了——IIS7自己就可以搞定了，現在IIS7可以直接從.NET程序集中調用HTTP modules和HTTP handlers了。當然，如果你願意的話，你仍然可以使用老的模式，依舊可以使用非託管的ISAPI擴展。

在IIS7中默認的模式是集成管線模式，但是如果你需要返回到傳統的管線模式的話，是可以在應用程序池配置界面中對管線模式進行調整的。

說明：圖中顯示默認添加了兩個應用程序池，其中一個使用的傳統管線模式，另一個是集成管線模式。

說明：你可以在具體網站的高級設置中配置所使用的應用程序池。

Asp.net是如何被關聯的

在集成管線模式中，IIS仍然根據URL文件擴展名來選擇處理程序（ISAPI擴展或.NET IHttpHandler類或者HttpHandler工廠）。同樣，你可以使用擴展名處理程序映射配置工具來配置擴展名和相應的處理程序。對ASP.NET請求來說不同的是，它不再需要通過aspnet_isapi.dll了——現在可以直接由IIS根據擴展名調用到相應的IHttpHandler處理程序了，比如默認的*.aspx到System.Web.UI.PageHandlerFactory。當你在伺服器上開啟ASP.NET服務的時候，所有的這些映射都已經自動設置好了。以前則是IIS根據擴展名把請求交給aspnet_isapi.dll，aspnet_isapi.dll再進一步根據擴展名甚至文件名把請求交給相應的IHttpHandler處理程序或者工廠的。

說明：IIS7中默認使用的是集成管線模式，默認情況下傳統模式也是開啟了，所以就有兩套擴展名與處理程序的映射配置，一套用於傳統模式，一套用於集成模式。可以看到，上圖顯示的是集成模式的配置——具有*.aspx擴展名的URL配置為最終交給System.Web.UI.PageHandlerFactory進行處理。注意，別忘了在到達PageHandlerFactory之前是已經經過了各個註冊的HttpModules的（在集成模式中，IIS不再需要一個非託管的ISAPI擴展程序來激活.NET代碼了——IIS7自己就可以完成了，現在IIS7可以直接從.NET程序集中調用HTTP modules和HTTP handlers）。

說明：該圖顯示的是傳統模式下對應於*.aspx擴展名的配置，可以看出——傳統模式下，具有*.aspx擴展名的URL是被IIS轉交給aspnet_isapi.dll了的，aspnet_iaspi.dll後還有HttpRuntime，HttpModule，並最終到達System.Web.UI.PageHandlerFactory。//可以參考上一篇

集成管線模式是如何使得製造無後綴的URL變得如此Easy的

重述要點，一個IHttpHandler類負責終結處理一類請求，每一個請求只能被一個處理程序處理（根據請求URL的擴展名來決定被哪一個IHttpHandler類來處理）。相比之下，IHttpModule類是插入在處理請求的管線內的，並且你可以在單個請求的處理流程中插入任意多個此類的IHttpModule。在IIS7里，即使那些最終不是被ASP.NET處理的請求也是要經過這些註冊了的IHttpModules的（不被ASP.NET處理的那些請求指的即是對非ASP.NET網站應用程序的請求，對靜態文件的請求等此類請求）。//參考上一篇

因為UrlRoutingModule是一個註冊了的IHttpModule（不是IHttpHandler），所以所有的請求都要經過它，請求需要經過管線中的IHttpModules是與URL擴展名和處理程序映射無關的事情。在UrlRoutingModule被調用的時候，它根據你的路由配置使路由系統嘗試匹配進來的URL請求信息，如果匹配到了第一個入口，接著就會把控制權轉交給你的一個controller類（或者一個自定義的IRouteHandler）。

UrlRoutingModule默認是被配置了的，因為當你創建一個新的空白的ASP.NET MVC網站應用程序的時候，你的web.config文件有一個<system.webServer>節點，如下：

<system.webServer>

</modules>

</system.webServer>

<system.webServer>節點是IIS7存取你的應用程配置數據的地方。所以，當你部署到IIS7的時候，無後綴URL再不需要任何其他手動設置的情況下即可工作了（如果一個無後綴的URL匹配了你的MVC路由配置的話，根據URL和匹配規則，controller和action即已經確定了。controller確定了，action確定了，再加上匹配的其他URL信息，包括QueryString，帶著這些初始信息以及封裝的請求上下文信息進入MVC框架，直到整個流程的完成都有源碼供你閱讀，因為ASP.NET MVC是開源的啊！趕快閱讀它吧！另外微軟開源的東西本來就少，並且從代碼量上說ASP.NET MVC的規模剛好適合閱讀，「它只有千餘行核心代碼//引用的老趙的話」相信你用幾天的時間就可以搞通它了，並且相信你的收穫會超出ASP.NET MVC本身之外。不閱讀的人是傻瓜^_^）。嗯，現在我明白了為什麼IIS7可以容易的製造出無後綴的URL了，你明白了嗎？不失完整性，下面是關於Visual Studio 2008內置Web伺服器的請求處理模式的。

在Visual Studio 2008的內置Web伺服器中是如何處理請求的

你可能已經注意到了，當你在Visual Studio 2008的內置Web伺服器中運行你的應用程序的時候，路由系統工作正常（Yes!無後綴！）。這是因為webdev.webserver.exe總是交由ASP.NET處理所有的請求，所以UrlRoutingModule總是被調用了。

但是，這可導致不愉快的事情發生，因為在我們隨後將做好的Web應用程序部署到IIS6的時候事情變得複雜，發現事情並沒有像在Visual Studio的集成Web伺服器上那麼簡單。幸好，解決方案總是存在，下一遍一起學習。

說實話，要是僅僅是部署ASP.NET MVC應用程序的話，並沒有那麼複雜，無需長篇累牘的扯蛋。如果通過這些文字能夠對初學者的知識起到編織作用從而有助於形成知識體系的話，目的已經達到了。