異步請求處理是ASP.NET 2.0中引入的高級特性，它依托IO Complete Port，對于提高IO密集型應(yīng)用程序的吞吐量非常重要（詳見原理描述和性能測試）。但是目前ASP.NET MVC框架缺少異步Action功能，這也就是老趙經(jīng)常掛在嘴邊的那個“目前ASP.NET MVC所缺少的非常重要的功能”。在TechED 2008 China的Session中我曾經(jīng)給出過一個所謂的“解決方案”，但是它復(fù)雜性之高使那個解決方案有太多限制。

為了彌補TechED上的遺憾，以及準備.NET開發(fā)大會上的ASP.NET MVC***實踐的Session，我在春節(jié)休假期間仔細思考了一下這方面的問題，得出了一個相對不錯的擴展：完整，方便，并且非常輕巧——核心邏輯代碼只有200行左右，這意味著絕大部分功能將會委托給框架中現(xiàn)成的內(nèi)容，確保了擴展的穩(wěn)定，高效并且擁有較好的向后兼容性。

值得一提的是，我在1/26號便基于ASP.NET MVC的Beta版本寫出了這個擴展的***個版本，而在不久之后微軟發(fā)布了ASP.NET MVC RC。我在移植解決方案的過程中發(fā)現(xiàn)ASP.NET MVC RC在框架設(shè)計上進行了較大的改進，這使得我在構(gòu)建擴展時的策略發(fā)生了些許變化。令人欣喜的是，RC版本的這些變化對于構(gòu)建一個擴展，尤其是現(xiàn)在這種“低端”級別的擴展變得更加容易。ASP.NET MVC框架實現(xiàn)了它“到處可擴展”的承諾。

那么我們現(xiàn)在就來詳細分析一下這個擴展的實現(xiàn)方式。

請求處理方式的改變

在制定基本改造策略之前，我們需要了解ASP.NET MVC框架目前的架構(gòu)及請求處理流程。如下：

在應(yīng)用程序啟動時（此時還沒有接受任何請求），將針對MVC請求的Route策略注冊至ASP.NET Routing模塊。此時每個Route策略（即Route對象）中的RouteHandler屬性為ASP.NET MVC框架中的MvcRouteHandler。

當ASP.NET Routing模塊接收到一個匹配某個Route策略的HTTP請求時，將會調(diào)用該Route對象中RouteHandler對象的GetHttpHandler以獲取一個HttpHandler，并交由ASP.NET執(zhí)行。MvcRouteHandler永遠將返回一個MvcHandler對象。

MvcHandler在執(zhí)行時，將取出RouteData中的controller值，并以此構(gòu)建一個實現(xiàn)了IController接口的控制器對象，并調(diào)用IController接口的Execute方法執(zhí)行該控制器。

對于一個ASP.NET MVC應(yīng)用程序來說，大部分控制器將會繼承System.Web.Mvc.Controller類型。Controller類將會從RouteData獲取action值，并交給實現(xiàn)IActionInvoker接口的對象來執(zhí)行一個Action。
……

如果我們要將這個流程改造成異步處理，那么就要讓它符合ASP.NET架構(gòu)中的異步處理方式。ASP.NET架構(gòu)對于異步請求的處理可以體現(xiàn)在好幾種方式上，例如異步頁面，異步Http Module等，而最適合目前場合的做法自然是異步Http Handler。為實現(xiàn)一個異步Handler，我們需要讓處理請求的Handler實現(xiàn)IHttpAsyncHandler接口，而不是傳統(tǒng)的 IHttpHandler接口。IHttpAsyncHandler接口中的BeginProcessRequest和 EndProcessRequest兩個方法構(gòu)成了.NET中的APM（Aynchronous Programming Model，異步編程模型）模式，可以使用“二段式”的異步調(diào)用來處理一個HTTP請求。

您應(yīng)該已經(jīng)發(fā)現(xiàn)，如果我們要支持異步Action，就必須根據(jù)當前的請求信息來確認究竟是執(zhí)行一個IHttpHandler對象還是IHttpAsyncHandler對象。而在ASP.NET MVC框架在默認情況下是在Http Handler（即MvcHandler對象）內(nèi)部進行控制器的檢查，構(gòu)造和調(diào)用。這為時已晚，我們必須講這些邏輯提前到Routing過程中才行。幸運的是，ASP.NET Routing所支持的IRouteHandler就像是ASP.NET中的IHttpHandlerFactory，可以根據(jù)情況生成不同的Handler來執(zhí)行。因此，我們只要構(gòu)建一個新的IRouteHandler類型即可。于是就誕生了AsyncMvcRouteHandler——可以想象的出，其中的部分代碼與框架中的MvcHandler相同，因為在一定程度上我們的確只是把原本在MvcHandler里做的事情給提前了：

publicclassAsyncMvcRouteHandler:IRouteHandler  
{  
publicIHttpHandlerGetHttpHandler(RequestContextrequestContext)  
{  
stringcontrollerName=requestContext.RouteData.GetRequiredString("controller");  
 
varfactory=ControllerBuilder.Current.GetControllerFactory();  
varcontroller=factory.CreateController(requestContext,controllerName);  
if(controller==null)  
{  
thrownewInvalidOperationException(...);  
}  
 
varcoreController=controllerasController;  
if(coreController==null)  
{  
returnnewSyncMvcHandler(controller,factory,requestContext);  
}  
else  
{  
 
stringactionName=requestContext.RouteData.GetRequiredString("action");  
returnIsAsyncAction(coreController,actionName,requestContext)?  
(IHttpHandler)newAsyncMvcHandler(coreController,factory,requestContext):  
(IHttpHandler)newSyncMvcHandler(controller,factory,requestContext);  
}  
}  
 
internalstaticboolIsAsyncAction(  
Controllercontroller,stringactionName,RequestContextrequestContext)  
{  
...  
}  
} 

【編輯推薦】

1. 介紹ASP.NET 2.0虛擬主機
2. 淺談ASP.NET應(yīng)用程序
3. 優(yōu)化ASP.NET 2.0 Profile Provider
4. 淺談ASP.NET管道優(yōu)化
5. 介紹ASP.NET Routing引擎