设计模式:跨应用程序层管理异步任务

本文关键字：管理 异步 任务 应用程序 设计模式 | 更新日期: 2023-09-27 18:36:22

在 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/await 关键字，我仍然建议将任务返回给调用者。

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

    如果提供回调（
  1. 如示例中所示），则还必须指定回调输入参数（在示例中为字符串）和返回类型。这是一个不必要的限制
  2. 它更接近 async/await 模式，因此如果您在某个时候将实现它，那么代码就不会有这么大的变化。
    3. 将业务代码保留在业务层中，将调用方代码保留在调用方
  3. 所在的任何层中（而不是将调用方代码注入业务层）会更干净

正如您可能注意到的那样，这主要是我的意见在这里说话（除了#1，这是一个非常坚实的好处）。但这是我的经验所能给出的最佳答案（我也使用过没有异步/等待的任务，男孩是不是很痛苦）

相关文章：