使用标准.Net异步模式的优点？

我正在设计一个执行长时间运行任务的类。 我想出的第一个设计是：

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范例，更多地转向基于任务的异步（恕我直言）。

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

 public Task DoSomethingAsync(string param); 

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