多层 C# 应用程序中的 Async/Await

Question

我在高流量场景中有一个多层 C# MVC4 Web 应用程序，它为各种存储库使用依赖注入。这非常有用，因为它易于测试，并且在生产中我们可以轻松地为特定控制器配置存储库。所有控制器都继承自 AsyncController，因此返回 Task<JsonResult> 或 Task<ActionResult> 的操作方法真正帮助我们的服务器扩展更多用户和 solve for the dreaded thread starvation problem。一些存储库使用 Web 服务，我们绝对可以使用 Async/Await 来提供可扩展性优势。在其他情况下，有些人可能使用无法安全线程化的非托管服务，其中 async/await 不会提供任何好处。每个存储库都是一个接口 IRepository 的实现。简而言之，每种实现在获取数据的方式上都大不相同。此配置是在部署时通过 web.config 更改和 Autofac 模块选择的。

在这样的应用程序中实现 async/await 的推荐方法有哪些？为了使该模式适合我现有的应用程序，我必须更改接口以返回Task<MyBusinessObject>。 但这不是更多的实现细节吗？我可以提供两个方法存根，GetData 和 GetDataAsync，但对我来说，这不允许我现在使用 IoC 框架，如Autofac，我可以轻松地交换所有内容，而无需更改代码。

Async/Await 的一位 Microsoft 开发人员发表了一篇博文“Should I expose an asynchronous wrapper for my synchronous methods?”，这就是问题所在。如果您的异步方法不是真正的异步（提供本机 I/O 优势），那么它实际上只会增加开销。换句话说，它不会提供任何可扩展性优势。

我只是想知道社区的其他成员是如何解决这个问题的。

Answer 1

在您的情况下，我建议您将界面设为异步：

public interface IMyInterface
{
  Task<TMyResult> GetDataAsync();
}

对于同步方法，可以返回Task.FromResult：

public class MyImplementation : IMyInterface
{
  public Task<TMyResult> GetDataAsync()
  {
    TMyResult ret = ...;
    return Task.FromResult(ret);
  }
}

异步方法当然可以是async，使用await。

关于实施细节，我会说“是和不是”。 ;) 在这方面它与IDisposable 非常相似。从逻辑上讲，它是一个实现细节，因为它的实现方式无关紧要。在调用代码需要以不同方式处理它的意义上，它不是一个实现细节。所以我同意 - 从逻辑上讲 - 这是一个实现细节，但 .NET 平台还不够先进，无法将其视为这样。

另外，你可以这样想（这是我通常给出的解释）：async 是实际的实现细节，当你返回 Task<T> 而不是 T 时，你定义了一个接口其中实现可能是异步的。

我有一个series of blog posts，该地址使用async“大”进行设计（即，将async 与OOP 配合使用，而不是让它发挥作用）。我解决了一些常见问题，例如异步初始化和 IoC。这只是一个人的意见，但我不知道有任何其他资源可以解决这类问题。

附：在 MVC4 中，您不再需要从 AsyncController 继承。默认控制器处理程序将根据返回类型（Task 或 Task<T>）自动检测 async 方法。

Answer 2

Task 是一个有漏洞的抽象。如果您希望受益于 IO 完成端口线程的使用，则必须将任务从您的存储库一路返回到您的控制器。

虽然让整个调用堆栈返回 Task<T> 可能会提高可伸缩性，但它确实为您的应用程序增加了一层额外的复杂性。这将阻碍可维护性、可测试性，并使推理代码变得更加困难。 Asynchronous code will always be harder than synchronous code.

就个人而言，我宁愿增加服务器的内存量并将应用程序配置为具有更大的线程池以补偿可伸缩性的损失，或者横向扩展到一些额外的（虚拟）服务器，而不是增加这种额外的复杂性.