建站
咨詢
售后
建站咨詢
新聞中心
異步請求處理是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ù)雜性之高使那個解決方案有太多限制。
成都創(chuàng)新互聯(lián)公司自2013年起，先為益陽等服務(wù)建站，益陽等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為益陽企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。
為了彌補TechED上的遺憾，以及準(zhǔn)備.NET開發(fā)大會上的ASP.NET MVC***實踐的Session，我在春節(jié)休假期間仔細(xì)思考了一下這方面的問題，得出了一個相對不錯的擴展：完整，方便，并且非常輕巧——核心邏輯代碼只有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è)計上進(jìn)行了較大的改進(jìn)，這使得我在構(gòu)建擴展時的策略發(fā)生了些許變化。令人欣喜的是，RC版本的這些變化對于構(gòu)建一個擴展，尤其是現(xiàn)在這種“低端”級別的擴展變得更加容易。ASP.NET MVC框架實現(xiàn)了它“到處可擴展”的承諾。
那么我們現(xiàn)在就來詳細(xì)分析一下這個擴展的實現(xiàn)方式。
請求處理方式的改變
在制定基本改造策略之前，我們需要了解ASP.NET MVC框架目前的架構(gòu)及請求處理流程。如下：
在應(yīng)用程序啟動時（此時還沒有接受任何請求），將針對MVC請求的Route策略注冊至ASP.NET Routing模塊。此時每個Route策略（即Route對象）中的RouteHandler屬性為ASP.NET MVC框架中的MvcRouteHandler。
當(dāng)ASP.NET Routing模塊接收到一個匹配某個Route策略的HTTP請求時，將會調(diào)用該Route對象中RouteHandler對象的GetHttpHandler以獲取一個HttpHandler，并交由ASP.NET執(zhí)行。MvcRouteHandler永遠(yuǎn)將返回一個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ù)當(dāng)前的請求信息來確認(rèn)究竟是執(zhí)行一個IHttpHandler對象還是IHttpAsyncHandler對象。而在ASP.NET MVC框架在默認(rèn)情況下是在Http Handler（即MvcHandler對象）內(nèi)部進(jìn)行控制器的檢查，構(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)
- {
- ...
- }
- }
網(wǎng)頁標(biāo)題：概述ASP.NETMVC框架
文章起源：http://www.5511xx.com/article/djjgcso.html
