嵌套和继承 async/Tasks

Question

我正在研究一个 PCL，它有一个 async API（我是这个主题的新手）。根据我在网上所做的研究，我对行为和设计的影响感到困惑。假设应用程序使用了一些入口点 API，它包裹了一些抽象的底层来访问文件。假设此代码是运行客户端。

public interface IFileProcessor
{
    Task ProcessFile(string filename);
}

public class MyFileProcessor : IFileProcessor
{
    // Adapter can be SomeAdapter or SomeOtherAdapter
    private IMyAdapter _adapter;

    public Task ProcessFile(string filename)
    {
        File file = await _adapter.GetFileAsync(filename).ConfigureAwait(false);

        // Some CPU bound operation
        DoSomeWorkOnFile(file);

        await _adapter.SaveAsync(file);
    }

    private void DoSomeWorkOnFile(File file)
    {
        // do some CPU heavy work here
    }
}

internal interface IMyAdapter
{
    Task<File> GetFileAsync(string filename);
    Task SaveAsync(File file);
}

// Some adapter for a client that has an async API and is mainly I/O bound
internal class SomeAdapter : IMyAdapter
{
    private SomeClient _client;

    public async Task<File> GetFileAsync(string filename)
    {
        // Fetch from server or something
        return await _client.SearchForFileAsync(filename).ConfigureAwait(false);
    }

    public async Task SaveAsync(File file)
    {
        // Push to server or something
        await _client.SaveFileAsync(file).ConfigureAwait(false);
    }
}

但是假设我有另一个没有 async API 的适配器并且它的操作正在阻塞：

// Some adapter for a client that has no async API and is mainly I/O bound
internal class SomeOtherAdapter : IMyAdapter
{
    private SomeOtherClient _client;

    // Don't declare as async since it can't await?
    public Task<File> GetFileAsync(string filename)
    {
        // Read from disk or something
        File file = _client.GetFile(filename);
        return Task.FromResult(file);
    }

    public Task SaveAsync(File file)
    {
        // Write to disk or something
        _client.Save(file);
    }
}

尽管存在行为差异，SomeOtherAdapter 是否有任何企业实施 IMyAdapter？
拥有 IMyAdapter return Task 类型有什么好处吗？推测应用程序调用 await MyFileProcessor.DoSomeWorkAsync(...)，那么为什么让适配器为 async？
这些操作主要是 I/O 绑定，而不是 CPU 绑定 - 这会影响我设计这些组件的决定吗？

我知道很难在一个简单的例子中抓住核心问题，所以如果我给出的例子太琐碎而无法清楚地表达我的问题，我深表歉意。

额外问题：如果 MyFileProcessor 不需要做任何 CPU 绑定工作，那么使用 async 有什么好处吗？

Answer 1

Does SomeOtherAdapter have any business implementing IMyAdapter despite the behavioral differences?

是的。当你处理接口时，任务返回方法表明它可能可能是异步的。如果您有一个真实的（即非测试存根）同步实现，我会在接口本身的文档中指出方法调用实际上可能是同步的。

Is there any benefit to having IMyAdapter return Task types? Presumably the application calls await MyFileProcessor.DoSomeWorkAsync(...), so why let the adapters be async?

是的。您的第一个示例是异步的 I/O-bound 操作，因此使接口返回任务（即异步兼容）是完全有意义的。

These operations are mainly I/O bound, not CPU bound - should that impact my decision in how I would design these components?

是的。任何时候你有一个可能异步实现的接口，它应该有那些方法的异步兼容签名。

If MyFileProcessor doesn't need to do any CPU bound work, is there any benefit to using async at all?

这个问题我没看懂；这似乎暗示 async 应该用于 CPU-bound 工作。但这与异步的工作方式相反； async 非常适合 I/O-bound 代码，而不是 CPU 绑定代码。

您可能对我的 async OOP 博客系列感兴趣。

嵌套和继承 async/Tasks

Nesting and inheriting async/Tasks

.net

c#

cross-platform

async-await