限制和缺点
　　
  如果这个解决方案没有缺陷，那么相信它已经被放入ASP.NET MVC 1.0中，而轮不到我在这里扩展一番了。目前的这个解决方案至少有以下几点不足：

  没有严格遵守.NET中的APM模式，虽然不影响功能，但这始终是一个遗憾。

  由于利用了框架中的现成功能，所有的Filter只能运行在BeginXxx方法上。

  由于EndXxx方法和最终ActionResult的执行都没有Filter支持，因此如果在这个过程中抛出了异常，将无法进入ASP.NET MVC建议的异常处理功能中。
　　
  根据ASP.NET MVC框架的Roadmap，ASP.NET MVC框架1.0之后的版本中将会支持异步Action，相信以上这些缺陷到时候都能被弥补。不过这就需要大量的工作，这只能交给ASP.NET MVC团队去慢慢执行了。事实上，您现在已经可以在ASP.NET MVC RC源代码的MvcFutures项目中找到异步Action处理的相关内容。它添加了IAsyncController，AsyncController，IAsyncActionInvoker，AsyncControllerActionInvoker等许多扩展。虽说它们都“继承”了现有的类，但是与我之前的判断相似，如AsyncControllerActionInvoker几乎完全重新实现了一遍ActionInvoker中的各种功能——我还没有仔细阅读代码，因此无法判断出这种设计是否优秀，只希望它能像ASP.NET MVC本身那样的简单和优雅。

  接下来，我打算为现在的代码的EndXxx方法也加上Filter支持，我需要仔细阅读ASP.NET MVC的源代码来寻找解决方案。希望它能够成为ASP.NET MVC正式支持异步Action之前较好的替代方案。