受争论的【基于事件的异步模式】
本来在我的写作计划中，是没有这段文字的，可就在我打算发布这篇博客之前，想到上篇博客中的评论，突然我想到一本书：CLR via C# 。是的，就是这本书，我想很多人手里有这本书，想到这本书是因为上篇博客的评论中，出现一个与我的观点有着不一致的声音(来自AndersTan)，而他应该是Jeffer Richter的粉丝。我早就买了这本书了(中文第三版)，其实也是AndersTan推荐的，不过一直没有看完，因此，根本就没有发现Jeffer Richter是【基于事件的异步模式】的反对者，这个可参考书中696页。Jeffer Richter在书中说：“由于我不是EAP的粉丝，而且我不赞同使用这个模式， 所以一直没有花太多的时间在它上面。然而，我知道有一些人确实喜欢这个模式，而且想使用它，所以我专门花了一些时间研究它。” 为了表示对大牛的敬重，我用蓝色字体突出他说的话(当然是由周靖翻译的)。看到这句话以及后面他对于此模式的评价，尤其是在【27.11.2 APM和EAP的对比】这个小节中对于EAP的评价，让我感觉大牛其实也没有很有地了解这个模式。
这里再补充一下，书中提到二个英文简写：EAP: Event-base Asynchronous Pattern, APM: Asynchronous Programming Model 。书中689页中，Jeffer Richter还说过：“虽然我是APM的超级粉丝，但是我必须承认它存在的一些问题。” 与之相反，虽然我不是APM的忠实粉丝，我却不认为他所说的问题真的是APM的缺点。他说的第一点，感觉就没有意义。我不知道有多少人在现实使用中，是在调用了Begin方法后，立即去调用End方法?我认为.net允许这种使用方式，可能还是更看中的是使用上的灵活性，毕竟微软要面对的开发者会有千奇百怪的要求。而且MSDN中也解释了这种调用会阻塞线程。访问IAsyncResult是可以一个WaitHandle，这个好像在上篇博客的评论中有人也提过了，我当时也不想说了，这次就把我的实现方式贴出来了，只希望告诉一些人：这个成员虽然是个耗资源的东西，但要看你如何去实现它了：有些时候(完成的时候)可以返回null的，所以，通常应该设计成一种延迟创建模式才对(我再一次的提醒：在设计它时要考虑多线程的并发访问)。
刚才扯远了，我们还是来说关于Jeffer Richter对于【27.11.2 APM和EAP的对比】这个小节的看法(699页)。这个小节有4个段话，分别分4个方面说了些EAP的【缺点】，我也将依次来发表我的观点。
Jeffer Richter认为EAP的最大优点在于和IDE的配合使用，且在后面一直提到GUI线程。显然EAP模式被代表了，被WinForm这类桌面程序程序代表了。我今天的示例代码一直是可以在ASP.NET环境下运行的，而且还特意和WinForm下的使用方法做了比较，结果是：使用方式基本相同。 我认为这个结果才是EAP模式最大的优点：在不同的编程模型中不必考虑线程模型问题。
Jeffer Richter说：事实上，EAP必须为引发的所有进度报告和完成事件分配从EventArgs派生的对象......。看到这句话的感觉还是和上句话差不多：被代表了。 对于这段话，我认为有必要从几个角度来表达我的观点：
进度报告：我想问一句：ASP.NET编程模型下进度报告有什么意义，或者说如何实现?在我今天演示的示例代码中，我一直没演示进度报告吧?事实上，我的包装类中根本就不提供这个功能，只提供了完成事件的功能。再说，为什么需要进度报告?因为桌面程序需要，它们为了能让程序拥有更好的用户体验。当然也可以不提供进度报告嘛，大不了让用户守在电脑面前傻等就是了，这样还会有性能损失吗?当然没有，但是用户可能会骂人......。
性能损失：MyAysncClient是对一个更底层的静态方法调用的封装。我也很明白：有封装就有性能的损失。但我想：一次异步任务也就只通知一次，性能损失能有多大?而且明知道有性能损失，我为什么还要封装呢?只为一个很简单的理由：使用起来更容易!
对象的回收问题：如果按照Jeffer Richter的说法，多创建这几个对象就让GC为难的话，会让我对.NET失去信心，连ASP.NET也不敢用了，因为要知道.NET的世界是完全面向对象的世界，一次WEB请求的处理过程中，ASP.NET不知道要创建多少个对象，我真的数不清楚。
Jeffer Richter说：如果在登记事件处理方法之前调用XxxAsync方法，......。看到这里，我笑了。显然，大牛是非常讨厌EAP模式的。EAP是使用了事件，这个错误的调用顺序问题如果是EAP的错，那么.NET的事件模式就是个错误的设计。大牛说这句真是不负责任嘛。
Jeffer Richter说：“EAP的错误处理和系统的其余部分也不一致，首先，异步不会抛出。在你的事件处理方法中，必须查询;AsyncCompletedEventArgs的Exception属性，看它是不是null ......” 看到这句话，我突然想到：一个月前在同事的桌上看到Jeffery Zhao 在【2010第二届.NET技术与IT管理技术大会 的一个 The Evolution of Async Programming on .NET Platform】培训PPT，代码大致是这样写的：
Exception Error { get; }
TResult Result { get; }
}
所以，我怀疑：Jeffer Richter认为EAP模式在完成时的事件中，异常也结果也是这样分开来处理的!
大家不妨回想一下，回到Jeffery Richter所说的APM模式下，我们为了能得到异步调用的结果，去调用End方法，结果呢，如果异步在处理时，有异常发生了，此时会抛出来。是的，我也同意使用这种方式来明确的告之调用者：此时没有结果，只有异常。
我们还是再来看一下我前面一直使用的一段代码：
{
if( e.Error == null )
labMessage.Text = string.Format("{0} => {1}", e.UserState, e.Result);
else
labMessage.Text = string.Format("{0} => Error: {1}", e.UserState, e.Error.Message);
}
表面上看，这段代码确实有Jeffer Richter所说的问题：有异常不会主动抛出。
这里有必要说明一下：有异常不主动抛出，而是依赖于调用者判断返回结果的设计方式，是不符合.NET设计规范的。那我如果把代码写成下面的这样呢?
{
try {
labMessage.Text = string.Format("{0} => {1}", e.UserState, e.Result);
}
catch( Exception ex ) {
labMessage.Text = string.Format("{0} => Error: {1}", e.UserState, ex.Message);
}
}
什么，您不认为我直接访问e.Result，不会出现异常吗?
再来看一下，我写的事件参数类型吧，看看我是如何做的：
{
private TOut _result;
public CallCompletedEventArgs(TOut result, Exception e, bool canceled, object state)
: base(e, canceled, state)
{
_result = result;
}
public TOut Result
{
get
{
base.RaiseExceptionIfNecessary();
return _result;
}
}
}
其中，RaiseExceptionIfNecessary()方法的实现如下(微软实现的)：
{
if( this.Error != null ) {
throw new TargetInvocationException(SR.GetString("Async_ExceptionOccurred"), this.Error);
}
if( this.Cancelled ) {
throw new InvalidOperationException(SR.GetString("Async_OperationCancelled"));
}
}
让我们再来看前面的EAP模式中完成事件中的标准处理代码：
{
if( e.Error == null )
labMessage.Text = string.Format("{0} => {1}", e.UserState, e.Result);
else
labMessage.Text = string.Format("{0} => Error: {1}", e.UserState, e.Error.Message);
}
的确，这种做法对于EAP模式来说：是标准的处理方式：首先要判断this.Error != null ，为什么这个 不规范 的方式会成为标准呢?
我要再问一句：为什么不用try.....catch这种更规范的处理方式呢?
显然，我也演示了：EAP模式在获取结果时，也可以支持try.....catch这种方式的。在这里不用它的理由是因为：
对于if判断这类简单的操作来说，抛异常是个【昂贵】的操作。这种明显可以提高性能的做法，难道有错吗?
在.net设计规范中，还有Tester-Doer, Try-Parse这二类模式。我想很多人也应该用过的吧，设计它们也是因为性能问题，与EAP的理由是一样的。
再来总结一下。我的CallCompletedEventArgs类在实现时，有二个关键点：
一方面，事件类型要从AsyncCompletedEventArgs继承。
另一方面， 用只读属性返回结果，但在访问前，要调用基类的base.RaiseExceptionIfNecessary();
这些都是EAP模式中，正确的设计方式。什么是模式?这就是模式。什么是规范?这就是规范!
我们不能因为错误的设计，或者说，不尊守规范的设计，而造成的缺陷也要怪罪于EAP 。
结束语
异步是个很有用的技术，不管是对于桌面程序还是服务程序都是很用意义的。
不过，相对于同步调用来说，异步也是复杂的，但它的各种使用方式也是很精彩的。
如果，您认为阅读这篇博客让您有些收获，不妨点击一下右下角的【推荐】按钮。
如果，您希望更容易地发现我的新博客，不妨点击一下右下角的【关注 Fish Li】。
因为，我的写作热情也离不开您的肯定支持。
异步很精彩，故事没讲完，请继续关注我的后续博客。
谢谢您的阅读。
上篇博客：【C#客户端的异步操作】
链接地址：http://www.cnblogs.com/fish-li/archive/2011/10/23/2222013.html
