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

#1 楼

您的功能是什么颜色？
您可能会对Bob Nystrom的《功能是什么颜色》感兴趣。
在本文中，他描述了一种虚构的语言，其中：每个功能都有一个颜色：蓝色或红色。
红色功能可以调用蓝色或红色功能，没问题。
蓝色功能只能调用蓝色功能。

虽然是虚构的

在C ++中非常常见：
在C ++中，“ const”方法只能在this上调用其他“ const”方法。 IO函数。
在C＃中，同步函数只能调用同步函数2。

您已经意识到，由于这些规则，红色函数倾向于在代码库中散布。您插入一个，然后一点一点地将其移植到整个代码库中。强烈建议用于任何编程语言/编译器爱好者。
2不太正确，因为您可以调用异步函数并阻塞直到返回，但是...语言/运行时限制。
例如M：N线程的语言（例如Erlang和Go）没有async函数：每个函数都可能是异步的，并且其“光纤”将被简单地挂起，交换
C＃采用1：1线程模型，因此决定在语言中实现同步，以避免意外阻塞线程。
在存在语言限制的情况下，编码准则必须适应。

#2 楼

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

#3 楼

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

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

这里有两种思路：一种是创建多个方法，每个方法都调用另一种可能的私有方法，从而允许为行为提供可选参数或较小的更改，例如异步。另一种方法是将接口方法最小化为基本内容，而由调用者自己进行必要的修改。同步和异步调用，以避免每个调用加倍。 Microsoft倾向于采用这种思想，并且按照惯例，为了与Microsoft所支持的样式保持一致，您也必须拥有Async版本，几乎与接口几乎总是以“ I”开头的方式相同。让我强调一下，从本质上讲，这并没有错，因为在项目中保持一致的样式比以“正确的方式”做到更好，并且从根本上更改添加到项目中的开发样式更好。

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

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

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

#4 楼

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

那真是太酷了，没人会建议您更改它们的名称。级别对它们具有一些特定于其异步性质的结构。例如，

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只是通过返回类型内置在编译器中的一种模式，因此您不必手动链接事件

#5 楼

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


是否不异步/等待与“良好体系结构”原则相抵触的最佳实践？


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

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

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

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

在具有庞大API的大型系统中，将它们中的大多数实现为默认情况下的同步可能比独立管理API的每个部分更容易和更有效，特别是如果它们共享资源（文件系统，CPU，数据库，... ）。

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

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