尽管在ASP.NET MVC 1中是不能直接支持异步Action,但在ASP.NET MVC 2中已经正式支持ASP.NET中的异步请求处理方式,并且通过一种比较易于使用的方式提供给开发人员使用。只可惜,由于语言层面的约束,这种使用方式还是有些不便,而此时便是F#的用武之地了。
员工经过长期磨合与沉淀,具备了协作精神,得以通过团队的力量开发出优质的产品。成都创新互联坚持“专注、创新、易用”的产品理念,因为“专注所以专业、创新互联网站所以易用所以简单”。公司专注于为企业提供成都网站设计、网站制作、微信公众号开发、电商网站开发,微信小程序开发,软件按需制作等一站式互联网企业服务。
基于事件的异步模式
说起.NET中的异步编程模型,.NET程序员最熟悉的应该就是Begin/End方法了。例如在WebRequest类中,便有这样一对方法:
- var request = WebRequest.Create("http://www./");
- request.BeginGetResponse(ar =>
- {
- var response = request.EndGetResponse(ar);
- // use the response object
- }, null);
在调用WebRequest对象的BeginGetResponse方法之后,当前调用线程不会被阻塞,而在异步操作完成之后,便会调用一个回调函数(即这里使用Lambda表达式构造的代码快)进行通知,在这个回调函数中调用EndGetResponse方法便可以得到一个WebResponse对象作为结果。
在这个异步操作中,由于伟大的IOCP,我们可以使用极少数的线程同时发起成千上万个连接(豪不夸张,我曾经在IIS里进行Comet试验,同时建立起超过2w个连接进行通信)。不过,事实上在.NET中还有一种基于事件的异步模式(Event-based Asynchronous Pattern,EAP)。基于事件的异步编程的典型案例之一便是WebClient类:
- var client = new WebClient();
- client.DownloadStringCompleted += (sender, args) =>
- {
- var html = args.Result;
- // ...
- };
- client.DownloadStringAsync(new Uri("http://www./"));
基于事件的异步模式的关键便在于,它是使用事件来作为工作结束时的通知机制。它和Begin/End的异步模型有明显区别。例如,在发生错误时,对于Begin/End模型来说会在End方法调用时抛出异常,而对于基于事件的异步模式来说,它则是使用事件参数的Exception属性来告诉程序员是否有异常发生。如果Exception属性为null,则说明一切正常,否则它便返回异步调用过程中发生的异常。
在ASP.NET MVC中使用异步Action
当年我的Hack使用的是Begin/End异步编程模型,而ASP.NET MVC 2则使用了基于事件的异步模式。围绕这种模式,ASP.NET MVC的AsyncController还提供了相关的辅助方法,让异步Action的编写变得相对容易一些。这里我则直接引用MSDN上的示例来说明问题。首先,我们准备一个普通的同步Action:
- public class PortalController : Controller
- {
- public ActionResult News(string city)
- {
- var newnewsService = new NewsService();
- var headlines = newsService.GetHeadlines(city);
- return View(headlines);
- }
- }
与它等价的异步Action则为:
- public class PortalController : AsyncController
- {
- public void NewsAsync(string city)
- {
- AsyncManager.OutstandingOperations.Increment();
- var newnewsService = new NewsService();
- newsService.GetHeadlinesCompleted += (sender, e) =>
- {
- AsyncManager.Parameters["headlines"] = e.Value;
- AsyncManager.OutstandingOperations.Decrement();
- };
- newsService.GetHeadlinesAsync(city);
- }
- public ActionResult NewsCompleted(string[] headlines)
- {
- return View("News", headlines);
- }
- }
很显然,异步Action也是标准的二段式调用,不过这个二段式调用却由比较特别的“约定”。在ASP.NET MVC 2中使用异步Action时,首先需要继承AsyncController类,并构造XyzAsync及XyzCompleted两个方法,前者返回void,后者返回ActionResult——这便表示一个异步的Action,名为Xyz。
ASP.NET MVC 2中对于异步Action的开发也提供了一定支持,这个支持便来自于AsyncManager。在发起异步操作之前,我们可以调用其OutstandingOperations对象的Increment方法,表示需要“进行几次异步操作”。
而每次异步操作结束之后,也就是在事件的处理函数中,便会调用对应的Decrement方法。这个方法表示“完成了一次异步操作”,而Decrement至零之后ASP.NET MVC便会得知所有的异步操作已经完成,于是便会调用XynCompleted方法,得到所需的ActionResult对象。
至于XyzCompleted方法所需要的参数,从代码中便可看出是通过AsyncManager的Parameters集合进行“过渡”的。这里有个不是很理想的地方,便是使用了字符串这种“弱类型”的方式,假设参数名改变,则对应的字符串也需要跟着改变。
选择Begin/End还是基于事件的异步模式?
很显然,在ASP.NET MVC中使用既可以使用Begin/End或是基于事件的异步编程模式,因为ASP.NET MVC本身只是根据AsyncManager的行为来进行异步操作。不过在ASP.NET MVC中,似乎更看重的是基于事件的异步模式。我估计,这是由于两种异步模式对于异常的行为差异所造成的吧。
正如我之前所提到的那样,在使用Begin/End异步模式时,如果出现了错误则会在End方法调用时抛出异常。要知道在回调函数中抛出异常是异步编程中最危险的情况(有没有之一?),如果没有正确地进行捕获则会让整个进程崩溃——当然,我们也可以在配置文件中设置成“忽略”,但是这明显也不妥当,例如会造成请求永远无法结束,直至超时,并且有可能造成资源泄露。
与之相对,使用基于事件的异步模式则不会出现这个问题,因为在这种情况下,事件一定会被正确调用,而异常则永远安安稳稳地保存在事件参数的Exception属性中。因此,使用Begin/End则需要额外的try...catch进行保护,使用基于事件的异步编程模式则会让代码变得精简一些。
当然,用着简单,也只是因为那些异常已经被异步操作的“提供方”给处理了。试想,WebClient之所以可以通过事件参数来暴露异常,一定是因为在它内部使用了try...catch。同理,如果我们要实现一个基于事件的异步模式,例如上面的NewsService,那也一定少不了对异常进行仔细处理。
文章题目:F#与ASP.NET:基于事件的异步模式与异步Action
标题来源:http://www.shufengxianlan.com/qtweb/news41/180641.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联