C＃中异步/等待用法的准则是否与好的架构和抽象分层的概念相矛盾？

这个问题与C＃语言有关，但我希望它涵盖其他语言，例如Java或TypeScript。

Microsoft建议在.NET中使用异步调用的最佳做法。在这些建议中，让我们选择两个：

• 更改异步方法的签名，以便它们返回Task或Task <>（在TypeScript中，这将是Promise <>）
• 更改异步方法的名称以xxxAsync（）结尾

现在，当用异步组件替换低级同步组件时，这会影响应用程序的整个堆栈。由于异步/等待仅在“一直使用”时才有积极影响，因此这意味着必须更改应用程序中每一层的签名和方法名称。

好的体系结构通常涉及在每个层之间放置抽象，这样高层组件就看不到用其他组件替换低层组件。在C＃中，抽象采用接口的形式。如果我们引入了一个新的，低级的异步组件，则调用堆栈中的每个接口都需要修改或替换为一个新接口。在实现类中解决问题（异步或同步）的方式不再对调用方隐藏（抽象）。调用者必须知道它是同步还是异步。

异步/等待与“良好架构”原则相抵触的最佳做法吗？

这是否意味着每个接口（例如IEnumerable，IDataAccessLayer）都需要它们的异步对应项（IAsyncEnumerable，IAsyncDataAccessLayer），以便在切换到异步依赖项时可以在堆栈中对其进行替换？

如果我们进一步推论这个问题，那么假设每个方法都是异步的（返回Task <>或Promise <>），并且使方法在实际上不是实际的情况下同步，会不会更简单？异步？这是将来的编程语言所期望的吗？

您的功能是什么颜色？

您可能对Bob Nystrom的《功能是什么颜色》¹感兴趣。

在本文中，他描述了一种虚构的语言，其中：

• 每个功能都有一种颜色：蓝色或红色。
• 红色功能可以调用蓝色或红色功能，没有问题。
• 蓝色功能只能调用蓝色功能。

尽管是虚构的，但在编程语言中却经常发生这种情况：

• 在C ++中，“ const”方法只能在上调用其他“ const”方法this。
• 在Haskell中，非IO功能只能调用非IO功能。
• 在C＃中，同步功能只能调用同步功能²。

正如您已经意识到的那样，由于这些规则，红色函数倾向于在代码库中散布。您插入一个，然后一点一点地殖民整个代码库。

¹ 除博客外，鲍勃·尼斯特罗姆（Bob Nystrom）还是Dart团队的一员，并撰写了这个小手工艺品译名系列；强烈推荐用于任何编程语言/编译器爱好者。

² 不太正确，因为您可能调用异步函数并阻塞直到返回，但是...

语言限制

本质上，这是语言/运行时限制。

例如，具有M：N线程的语言（例如Erlang和Go）没有async功能：每个功能都可能是异步的，并且其“纤维”将仅被挂起，换出并在再次准备好时换回。

C＃采用1：1线程模型，因此决定在语言中实现表面同步，以避免意外阻塞线程。

在存在语言限制的情况下，必须适应编码准则。

没错，这里有矛盾，但这并不是“最佳实践”不好。这是因为异步功能所做的本质上不同于同步功能。它无需等待其依赖项（通常是某些IO）的结果，而是创建了一个由主事件循环处理的任务。这不是可以很好地隐藏在抽象之下的差异。

我敢肯定，异步方法的行为与同步方法的行为有所不同。在运行时，将异步调用转换为同步调用是微不足道的，但是不能说相反的说法。因此，逻辑就变成了，为什么我们不对每个可能需要它的方法都使用异步方法，而让调用者根据需要“转换”为同步方法呢？

从某种意义上讲，这就像有一个抛出异常的方法，另一个是“安全的”并且即使发生错误也不会抛出异常的方法。编码器在什么时候过度提供这些方法，否则这些方法可以相互转换？

在这种情况下，有两种思路：一种是创建多个方法，每个方法都调用另一种可能的私有方法，从而允许为行为提供可选参数或较小的更改，例如异步。另一方法是将接口方法最小化，使其仅包含基本要素，而由调用者自己进行必要的修改。

如果您是第一所学校，则有一定的逻辑可将一类用于同步和异步调用，以避免每个调用加倍。Microsoft倾向于采用这种思想，并且按照惯例，要与Microsoft所支持的样式保持一致，您也必须拥有Async版本，其方式几乎与接口始终以“ I”开头的方式相同。让我强调一下，从本质上说，这并没有错，因为在项目中保持一致的样式比以“正确的方式”做事并从根本上更改添加到项目的开发的样式要好。

就是说，我倾向于第二所学校，即尽量减少接口方法。如果我认为某个方法可以异步方式调用，那么对我来说该方法是异步的。呼叫者可以决定在继续之前是否等待该任务完成。如果此接口是库的接口，则采用这种方法更合理，以最大程度减少您不赞成使用或调整的方法的数量。如果该接口供我的项目内部使用，我将为整个项目中的每个所需调用添加一个方法，以提供的参数，并且不添加任何“额外”方法，即使这样，前提是该方法的行为尚未涵盖通过现有方法。

但是，像该领域的许多事情一样，它在很大程度上是主观的。两种方法各有利弊。Microsoft还开始约定在变量名称的开头添加表示类型的字母，并使用“ m_”表示其是成员，从而导致变量名称（如）m_pUser。我的观点是，即使Microsoft也不是绝对可靠的，并且也会出错。

也就是说，如果您的项目遵循此异步约定，则建议您尊重它并继续使用该样式。而且只有给了自己的项目后，您才能以自己认为合适的最佳方式编写它。

假设有一种方法可以使您以异步方式调用函数而无需更改其签名。

那真的很酷，没有人会建议您更改他们的名字。

但是，实际的异步功能，不仅是等待另一个异步功能的异步功能，而且最低层的功能也具有特定于其异步特性的结构。例如

public class HTTPClient
{
    public HTTPResponse GET()
    {
        //send data
        while(!timedOut)
        {
            //check for response
            if(response) { 
                this.GotResponse(response); 
            }
            this.YouCanWait();
        }
    }

    //tell calling code that they should watch for this event
    public EventHander GotResponse
    //indicate to calling code that they can go and do something else for a bit
    public EventHander YouCanWait;
}

这是信息这两个位调用代码，以运行异步方式的代码之类的东西需要Task和async封装。

进行异步功能的方法不止一种，async Task只是通过返回类型在编译器中内置的一种模式，因此您不必手动链接事件

我将以较少的C＃ness方式和更通用的方式解决要点：

异步/等待与“良好架构”原则相抵触的最佳做法吗？

我要说的是，这仅取决于您在API设计中所做的选择以及您向用户提供的内容。

如果您希望API的一个功能仅是异步的，那么遵循命名约定就没有什么兴趣了。只是总是返回Task <> / Promise <> / Future <> / ...作为返回类型，这是自我记录。如果想要一个同步的答案，他仍然可以通过等待来完成，但是如果他总是这样做，这会有些重复。

但是，如果仅使API同步，则意味着如果用户希望它异步，则他必须自己管理它的异步部分。

这可以做很多额外的工作，但是，它还可以使用户更好地控制他所允许的并发呼叫数量，发出超时，重试等等。

在具有庞大API的大型系统中，与独立管理API的每个部分（尤其是共享资源（文件系统，CPU，数据库等）的情况）相比，默认情况下将大多数实现默认情况下进行同步可能更容易，更高效。

实际上，对于最复杂的部分，您可以完美地对API的同一部分进行两种实现，一种是同步处理方便的事情，一种异步依赖于同步处理一件事情，并且仅管理并发，负载，超时和重试。

也许其他人可以分享他的经验，因为我缺乏此类系统的经验。