F#與ASP.NET：基于事件的異步模式與異步Action
盡管在ASP.NET MVC 1中是不能直接支持異步Action，但在ASP.NET MVC 2中已經正式支持ASP.NET中的異步請求處理方式，并且通過一種比較易于使用的方式提供給開發人員使用。只可惜，由于語言層面的約束，這種使用方式還是有些不便，而此時便是F#的用武之地了。
基于事件的異步模式
說起.NET中的異步編程模型，.NET程序員最熟悉的應該就是Begin/End方法了。例如在WebRequest類中，便有這樣一對方法：
- var request = WebRequest.Create("http://www.jxzklqfsx.com/");
- 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）?；谑录漠惒骄幊痰牡湫桶咐槐闶荳ebClient類：
- var client = new WebClient();
- client.DownloadStringCompleted += (sender, args) =>
- {
- var html = args.Result;
- // ...
- };
- client.DownloadStringAsync(new Uri("http://www.jxzklqfsx.com/"));
基于事件的異步模式的關鍵便在于，它是使用事件來作為工作結束時的通知機制。它和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，那也一定少不了對異常進行仔細處理。
【編輯推薦】
