用任务异步方法包装回调异步方法的陷阱？答案

【问题标题】：Pitfalls of wrapping callback async methods with Task async methods?用任务异步方法包装回调异步方法的陷阱？
【发布时间】：2012-08-23 02:38:45
【问题描述】：

我正在为我的 WPF 应用程序创建一个服务层，它将包装一个使用 Action<T> 回调作为异步方法的 Web API 客户端。因为无论如何我都需要包装这些方法，所以我正在考虑使我的服务层的包装方法符合新的基于Task 的.NET 4.5 异步模式，而不是公开Action<T> 回调。

我目前没有迫切需要基于 Task 的异步，但我也没有任何理由必须坚持使用回调并且包装似乎很容易（如 here 所述）向后兼容性不是问题。也就是说，如果此类Action<T> 回调到 Tasks 包装有任何陷阱，我将保持现状。

【问题讨论】：

请记住，在处理任务之前，您始终必须捕获任务引发的异常（即围绕 Task.Wait 方法或类似方法进行尝试捕获），否则您将在发布版本！

标签： c# asynchronous task-parallel-library async-await c#-5.0

【解决方案1】：

我没有看到这样做有任何缺陷，事实上它会打开您的应用程序以分配更灵活的场景。我建议您还考虑将一些“回调”场景转换为观察者模式（参见 Microsoft 的 Reactive Extensions 项目），当与基于任务的模式结合使用时，它更加强大和灵活。当然，您将能够在 C# 5.0 中将新的基于任务的模式与新的异步/等待模式一起使用！

希望对你有帮助。

【讨论】：

“异步流”的另一个选项是 TPL 数据流。