F#與ASP.NET：基于事件的異步模式與異步Action
盡管在ASP.NET MVC 1中是不能直接支持異步Action，但在ASP.NET MVC 2中已經(jīng)正式支持ASP.NET中的異步請(qǐng)求處理方式，并且通過一種比較易于使用的方式提供給開發(fā)人員使用。只可惜，由于語言層面的約束，這種使用方式還是有些不便，而此時(shí)便是F#的用武之地了。
基于事件的異步模式
說起.NET中的異步編程模型，.NET程序員最熟悉的應(yīng)該就是Begin/End方法了。例如在WebRequest類中，便有這樣一對(duì)方法：
- var request = WebRequest.Create("http://www.scjtxx.cn/");
- request.BeginGetResponse(ar =>
- {
- var response = request.EndGetResponse(ar);
- // use the response object
- }, null);
在調(diào)用WebRequest對(duì)象的BeginGetResponse方法之后，當(dāng)前調(diào)用線程不會(huì)被阻塞，而在異步操作完成之后，便會(huì)調(diào)用一個(gè)回調(diào)函數(shù)（即這里使用Lambda表達(dá)式構(gòu)造的代碼快）進(jìn)行通知，在這個(gè)回調(diào)函數(shù)中調(diào)用EndGetResponse方法便可以得到一個(gè)WebResponse對(duì)象作為結(jié)果。
在這個(gè)異步操作中，由于偉大的IOCP，我們可以使用極少數(shù)的線程同時(shí)發(fā)起成千上萬個(gè)連接（豪不夸張，我曾經(jīng)在IIS里進(jìn)行Comet試驗(yàn)，同時(shí)建立起超過2w個(gè)連接進(jìn)行通信）。不過，事實(shí)上在.NET中還有一種基于事件的異步模式（Event-based Asynchronous Pattern，EAP）?；谑录漠惒骄幊痰牡湫桶咐槐闶荳ebClient類：
- var client = new WebClient();
- client.DownloadStringCompleted += (sender, args) =>
- {
- var html = args.Result;
- // ...
- };
- client.DownloadStringAsync(new Uri("http://www.scjtxx.cn/"));
基于事件的異步模式的關(guān)鍵便在于，它是使用事件來作為工作結(jié)束時(shí)的通知機(jī)制。它和Begin/End的異步模型有明顯區(qū)別。例如，在發(fā)生錯(cuò)誤時(shí)，對(duì)于Begin/End模型來說會(huì)在End方法調(diào)用時(shí)拋出異常，而對(duì)于基于事件的異步模式來說，它則是使用事件參數(shù)的Exception屬性來告訴程序員是否有異常發(fā)生。如果Exception屬性為null，則說明一切正常，否則它便返回異步調(diào)用過程中發(fā)生的異常。
在ASP.NET MVC中使用異步Action
當(dāng)年我的Hack使用的是Begin/End異步編程模型，而ASP.NET MVC 2則使用了基于事件的異步模式。圍繞這種模式，ASP.NET MVC的AsyncController還提供了相關(guān)的輔助方法，讓異步Action的編寫變得相對(duì)容易一些。這里我則直接引用MSDN上的示例來說明問題。首先，我們準(zhǔn)備一個(gè)普通的同步Action：
- public class PortalController : Controller
- {
- public ActionResult News(string city)
- {
- var newnewsService = new NewsService();
- var headlines = newsService.GetHeadlines(city);
- return View(headlines);
- }
- }
與它等價(jià)的異步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也是標(biāo)準(zhǔn)的二段式調(diào)用，不過這個(gè)二段式調(diào)用卻由比較特別的“約定”。在ASP.NET MVC 2中使用異步Action時(shí)，首先需要繼承AsyncController類，并構(gòu)造XyzAsync及XyzCompleted兩個(gè)方法，前者返回void，后者返回ActionResult——這便表示一個(gè)異步的Action，名為Xyz。
ASP.NET MVC 2中對(duì)于異步Action的開發(fā)也提供了一定支持，這個(gè)支持便來自于AsyncManager。在發(fā)起異步操作之前，我們可以調(diào)用其OutstandingOperations對(duì)象的Increment方法，表示需要“進(jìn)行幾次異步操作”。
而每次異步操作結(jié)束之后，也就是在事件的處理函數(shù)中，便會(huì)調(diào)用對(duì)應(yīng)的Decrement方法。這個(gè)方法表示“完成了一次異步操作”，而Decrement至零之后ASP.NET MVC便會(huì)得知所有的異步操作已經(jīng)完成，于是便會(huì)調(diào)用XynCompleted方法，得到所需的ActionResult對(duì)象。
至于XyzCompleted方法所需要的參數(shù)，從代碼中便可看出是通過AsyncManager的Parameters集合進(jìn)行“過渡”的。這里有個(gè)不是很理想的地方，便是使用了字符串這種“弱類型”的方式，假設(shè)參數(shù)名改變，則對(duì)應(yīng)的字符串也需要跟著改變。
選擇Begin/End還是基于事件的異步模式？
很顯然，在ASP.NET MVC中使用既可以使用Begin/End或是基于事件的異步編程模式，因?yàn)锳SP.NET MVC本身只是根據(jù)AsyncManager的行為來進(jìn)行異步操作。不過在ASP.NET MVC中，似乎更看重的是基于事件的異步模式。我估計(jì)，這是由于兩種異步模式對(duì)于異常的行為差異所造成的吧。
正如我之前所提到的那樣，在使用Begin/End異步模式時(shí)，如果出現(xiàn)了錯(cuò)誤則會(huì)在End方法調(diào)用時(shí)拋出異常。要知道在回調(diào)函數(shù)中拋出異常是異步編程中最危險(xiǎn)的情況（有沒有之一？），如果沒有正確地進(jìn)行捕獲則會(huì)讓整個(gè)進(jìn)程崩潰——當(dāng)然，我們也可以在配置文件中設(shè)置成“忽略”，但是這明顯也不妥當(dāng)，例如會(huì)造成請(qǐng)求永遠(yuǎn)無法結(jié)束，直至超時(shí)，并且有可能造成資源泄露。
與之相對(duì)，使用基于事件的異步模式則不會(huì)出現(xiàn)這個(gè)問題，因?yàn)樵谶@種情況下，事件一定會(huì)被正確調(diào)用，而異常則永遠(yuǎn)安安穩(wěn)穩(wěn)地保存在事件參數(shù)的Exception屬性中。因此，使用Begin/End則需要額外的try...catch進(jìn)行保護(hù)，使用基于事件的異步編程模式則會(huì)讓代碼變得精簡(jiǎn)一些。
當(dāng)然，用著簡(jiǎn)單，也只是因?yàn)槟切┊惓Ｒ呀?jīng)被異步操作的“提供方”給處理了。試想，WebClient之所以可以通過事件參數(shù)來暴露異常，一定是因?yàn)樵谒鼉?nèi)部使用了try...catch。同理，如果我們要實(shí)現(xiàn)一個(gè)基于事件的異步模式，例如上面的NewsService，那也一定少不了對(duì)異常進(jìn)行仔細(xì)處理。
【編輯推薦】
