F#与ASP.NET（1）：基于事件的异步模式与异步Action
2010-04-02 00:09 by 老赵, 4966 visits提高ASP.NET应用程序伸缩性的有效手段之一便是使用异步请求。而在ASP.NET MVC 1中是不能直接支持异步Action的，因此我们需要使用一些简单的Hack方式来实现这一点。不过简单的Hack毕竟无法利用ASP.NET MVC的完整功能，幸好ASP.NET MVC 2已经正式支持ASP.NET中的异步请求处理方式，并且通过一种比较易于使用的方式提供给开发人员使用。只可惜，由于语言层面的约束，这种使用方式还是有些不便，而此时便是F#的用武之地了。
基于事件的异步模式
说起.NET中的异步编程模型，.NET程序员最熟悉的应该就是Begin/End方法了。例如在WebRequest类中，便有这样一对方法：
var request = WebRequest.Create("http://blog.zhaojie.me/"); 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），这个编程模式也已经在《CLR via C# (3rd Edition)》中得到了正名（顺便一提，这本书我还差几十页就看完了，的确有相当大的更新，值得一看）。基于事件的异步编程的典型案例之一便是WebClient类：
var client = new WebClient(); client.DownloadStringCompleted += (sender, args) => { var html = args.Result; // ... }; client.DownloadStringAsync(new Uri("http://blog.zhaojie.me/"));
基于事件的异步模式的关键便在于，它是使用事件来作为工作结束时的通知机制。它和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 newsService = new NewsService(); var headlines = newsService.GetHeadlines(city); return View(headlines); } }
与它等价的异步Action则为：
public class PortalController : AsyncController { public void NewsAsync(string city) { AsyncManager.OutstandingOperations.Increment(); var newsService = 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#登场了。
深夜还在发表文章，不错。。。