使用标准.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;

IMO这些似乎使界面变得复杂，除了作为其他.Net开发人员可识别的模式之外没有任何真正的优势。 APM要求客户端代码始终在其completedCallback中调用EndDoSomething（），并且EAP需要单独订阅已完成的事件。

使用我缺少的标准模式有哪些优势？

Answer 1

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

然而，随着TPL和.Net4的引入以及新.Net4.5版本的进一步集成，似乎.Net正在逐渐远离IAsyncResult / Begin End范例，更多地转向基于任务的异步（恕我直说）。 / p>

所以，把新的方式投入到混合中：

public Task DoSomethingAsync(string param);

然后所有与取消/访问结果相关的操作都可以在Task对象上获得，这允许正确抽象异步机制，因为任何消费者只依赖于Task而不是工作的'发起者'和句柄归还。