使用标准的.Net异步模式有哪些优势？

Question

我正在设计一个执行长时间任务的类。我最初想到的设计是：

public TaskHandle DoSomethingAsync(DoSomethingCompleteCallback completedCallback);
public void       CancelDoSomething(TaskHandle handle);

这很简单明了。但是，我在想是否应该将其实现为我一直在阅读的标准.Net异步模式之一?

APM：

public IAsyncResult BeginDoSomething(AsyncCallback completedCallback, Object stateObject);
public void         EndDoSomething(IAsyncResult asyncResult);

EAP:

public void  DoSomethingAsync(string param, object userState);
public event DoSomethingCompletedEventHandler DoSomethingCompleted;

我认为这些模式似乎只是为了让其他 .Net 开发人员能够识别而增加了界面上的复杂性。APM 要求客户端代码在 completedCallback 中始终调用 EndDoSomething()，而 EAP 需要单独订阅 completed 事件。

那么，如果有的话，使用标准模式的优点是什么？我是否遗漏了什么重要的信息？

- GazTheDestroyer

Answer 1

这些模式唯一的优点是其他开发人员可以立即识别它们，并且可能在框架中得到支持（例如WCF中的begin end支持）。

然而，随着TPL在.Net4中的引入和在新的.Net4.5版本中进一步集成，.Net似乎正在远离IAsyncResult/Begin End范例，更加倾向于基于任务的异步编程方式（在我看来更可取）。

因此，让我们将这种新方法加入到混合中：

public Task DoSomethingAsync(string param);

然后，所有与取消/访问结果相关的操作都可以在任务对象上执行，这样可以正确地抽象异步机制，因为任何消费者仅依赖于任务而不是工作的“启动者”和返回的句柄。

- Rich O'Kelly

---

对于任务为基础的编程方法，我们给予加分。微软正在采用这种方法，而不是之前的异步模式。如果使用这种方法，代码将具备一定的未来性。 - spender

是的，我对这个有所了解，一开始感到很高兴，但后来才意识到这只是预览版。在它正式发布之前，我不太放心采用它。 - GazTheDestroyer

@GazTheDestroyer 目前已经存在基于任务的处理方式，可以看看任务并行库。 - Rich O'Kelly

太棒了，谢谢。我一直在阅读关于await关键字的内容，所以我以为任务异步模式也是类似的预览版。这里有一个很好的概述供其他人参考：http://www.microsoft.com/download/en/confirmation.aspx?id=19957 - GazTheDestroyer