设计模式：跨应用层管理异步任务答案

【问题标题】：Design Pattern: Managing an async task across application layers设计模式：跨应用层管理异步任务
【发布时间】：2016-06-10 05:27:52
【问题描述】：

使用 C# 中的任务编写异步方法的新手。这是一个关于如何架构跨应用层调用异步任务的问题。

我有一个对服务器进行 REST 调用的数据访问层。我为每个服务器调用实现了异步方法，每个都返回一个任务。

我有一个调用数据访问层的业务逻辑层。对业务逻辑层的异步请求会接受一个回调，一旦使用ContinueWith() 完成任务，就会执行该回调。因此，异步执行的详细信息包含在业务逻辑层中。

我想知道这种设计选择是否有意义，或者我的业务层将 Task 对象传递给它的调用者是否会更好？

这是我目前拥有的DateManager 的一个示例。没有await，我写的就像我在这里一样。但是，从我的视图控制器来看，现在使用回调调用 DateManager.GetTradeDate() 可能会很尴尬。

public class DateManager : IDateManager
{
    public void GetTradeDate(string dt, Action<string> callback)
    {
        DateManagerClient dmc = new DateManagerClient();
        Task<string> t = dmc.GetTradeDateAsync(dt);
        t.ContinueWith(x =>
        {
            callback(x.Result);
        });
    }
}

【问题讨论】：

通常async 的口头禅是“一直异步”。也就是说，如果任何给定的方法内部有一个async 操作，那么它应该await 那个操作并且它本身应该是async。一直到调用它的顶级应用程序技术。在同步操作后面“隐藏”async 操作是有问题的。
听起来有点不对劲，您不需要为异步方法提供回调...您只需要等待异步方法并从那里继续。但我可能误解了这个场景，您能否提供一些代码来说明您到目前为止所拥有的内容？
我用的是VS2010，所以没有await和async。我尝试在我的业务层中使用回调来做这件事，但了解到我可以只使用我的 RestClient 使用的任务。现在我有两个范式。添加了一个代码示例来展示我是如何做到的。但是，我喜欢 @David 的建议，即应该重复异步模式。
@gdbj：无论是使用async/await 还是其他方式，我认为总体规则应该仍然成立。尽可能将任务一直公开到顶层。让消费应用程序/技术处理任务的同步。如果您仍然需要手动编写代码来处理它，那很好。我只是强烈认为代码应该在应用程序层，除非有真正令人信服的理由。如果有这样的原因，请非常小心不要重新发明async void 反模式。确保处理错误情况。

标签： c# asynchronous task

【解决方案1】：

即使您不能使用 async/await 关键字，我仍然建议将任务返回给调用者。

我建议这样做有几个原因：

如果您提供回调（如在您的示例中），您还必须指定回调输入参数（在您的示例中为字符串）和返回类型。这是不必要的限制
它更接近 async/await 模式，因此如果您在某个时间点实现它，那么它不会对代码进行如此大的更改。
将业务代码保留在业务层中，将调用者代码保留在调用者所在的任何层中（而不是将调用者代码注入业务层）会更简洁

您可能会注意到，这里主要是我的观点（除了#1，这是一个非常可靠的好处）。但这是我可以根据我的经验给出的最佳答案（我也使用过没有 async/await 的任务，男孩是不是很痛苦）

【讨论】：