c# - 使用 DRY 和分而治之原则链接的异步方法

Question

假设我们有以下方法:

private async Task<string> Foo(string parameter)
{
    // Some code to convert source parameter
    string convertedParameter = //value;

    CallResult callResult;
    try
    {
        var integerResult = await LoadInformationAsync(convertedParameter);
        if (integerResult > 0)
        {
            callResult = // Some logic to analyse integerResult and generate CallResult object
        }
        else
        {
            callResult = // Some logic to analyse integerResult and generate CallResult object
        }
    }
    catch (Exception ex)
    {
        callResult = CallResult.Default; // some default value if call failed
    }

    var stringResult = // some logic to convert callResult instance to some another string result;

    return stringResult; //Finally return the result
}

让我们不要深入细节。主要是此方法包含一些业务逻辑和调用(假设 3d 方)方法 LoadInformationAsync 可等待。

这些评论的背后可能是大量的业务逻辑，所以我认为，每个人都会同意将逻辑拆分为单独的方法(甚至类)绝对是好的。

因此，LoadInformationAsync 方法的核心调用将深入调用堆栈。像这样:

private async Task<string> Foo(string parameter)
{
    // Some code to convert source parameter
    string convertedParameter = //value;

    CallResult callResult = await MakeSafeCall(convertedParameter);

    var stringResult = // some logic to convert callResult instance to some another string result;

    return stringResult; //Finally return the result
}

private async Task<CallResult> MakeSafeCall(string parameter)
{
    try
    {
        var integerResult = await LoadInformationAsync(convertedParameter);
        if (integerResult > 0)
        {
            return callResult = // Some logic to analyse integerResult and generate CallResult object
        }
        else
        {
            return callResult = // Some logic to analyse integerResult and generate CallResult object
        }
    }
    catch (Exception ex)
    {
        return CallResult.Default;
    }
}

因此，我们的代码稍微好一些。 F.e.是一些类/方法可能想要调用方法 MakeSafeCall 来尝试/捕获。

但是我们现在有什么？我们有一个额外的异步方法需要等待。每对 async/await 都会带来一个捕获上下文等的状态机。好的，我们可以处理这个开销，但是如果我们有更复杂的逻辑(而且我们经常这样做)迫使我们将我们的根方法拆分成更小的和平怎么办。我们的异步/等待对计数将会增加。而且好像也不是很好。

那么问题来了:在这种情况下使用 async/await 的好的模式是什么？

Answer 1

我认为 Stephan Toub 在他的文章 Async Performance: Understanding the Costs of Async and Await 中很好地回答了您的问题

Asynchronous methods are a powerful productivity tool, enabling you to more easily write scalable and responsive libraries and applications. It’s important to keep in mind, though, that asynchronicity is not a performance optimization for an individual operation. Taking a synchronous operation and making it asynchronous will invariably degrade the performance of that one operation, as it still needs to accomplish everything that the synchronous operation did, but now with additional constraints and considerations. A reason you care about asynchronicity, then, is performance in the aggregate: how your overall system performs when you write everything asynchronously, such that you can overlap I/O and achieve better system utilization by consuming valuable resources only when they’re actually needed for execution. The asynchronous method implementation provided by the .NET Framework is well-optimized, and often ends up providing as good or better performance than well-written asynchronous implementations using existing patterns and volumes more code. Any time you’re planning to develop asynchronous code in the .NET Framework from now on, asynchronous methods should be your tool of choice.

底线是，不要过早优化。如果您对代码进行基准测试并发现 async 方法是一个瓶颈，请查看它在幕后做了什么以及如何编写更注重性能的代码。但是请记住，.NET Framework 团队在实现 async-await 时考虑到了这一点，您可以在细节中看到这一点，例如将 AsyncTaskMethodBuilder 设置为结构而不是类以减少 GC 压力等。

我建议您通读 stephans 的文章，以更好地了解框架所做的成本/优化。