使用标准.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范式,更多地转向基于任务的异步(恕我直说).

所以,把新的方式投入到混合中:

public Task DoSomethingAsync(string param);

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