用于 Net Core 的 Net Standard 库中带或不带 ConfigureAwait 的异步方法

Question

我有一个正在执行批量插入的库。
库是在 .NetStandard(1.4) 中制作的 EfCore 扩展，因此它可用于面向 .NetCore(1.0+) 或完整 NetFramework(4.6.1+) 的 ASP.NET Core 项目
其中一个功能是：

public static BulkInsert<T>(this DbContext context, IList<T> entities)
{
    SqlBulkOperation.InsertAsync<T>(context, entities);
}

internal static class SqlBulkOperation
{
    public static void Insert<T>(DbContext context, IList<T> entities)
    {
        ....
        sqlBulkCopy.WriteToServer(reader);
        ....
    }
}

接下来我添加了具有异步支持的相同方法

public static async Task BulkInsertAsync<T>(this DbContext context, IList<T> entities)
{
    await SqlBulkOperation.InsertAsync<T>(context, entities, null, null);
}

internal static class SqlBulkOperation
{
    public static async Task InsertAsync<T>(DbContext context, IList<T> entities)
    {
        ....
        await sqlBulkCopy.WriteToServer(reader);
        ....
    }
}

现在有人建议我更改异步方法，将 ConfigureAwait(false) 添加到内部方法中，并通过删除显式 async 来优化简单的 async em>async 来自公开方法的关键字，如下所示：

public static Task BulkInsertAsync<T>(this DbContext context, IList<T> entities)
{
    return SqlBulkOperation.InsertAsync<T>(context, entities, null, null, true);
}

internal static class SqlBulkOperation
{
    public static async Task InsertAsync<T>(DbContext context, IList<T> entities)
    {
        await sqlBulkCopy.WriteToServerAsync(reader).ConfigureAwait(false);
    }
}

所以问题是：
在这种情况下使用 ConfigureAwait(false) 更好吗？
其次是从公开的方法中删除 async 关键字以用于示例中的场景是否可取？

PS 我已经阅读了一些关于这些问题的博客和几个问题，但还没有得出结论性的答案。 我读到 ASP.NET Core 不再有“上下文”，所以考虑到这里的最佳实践是什么？

Answer 1

在这种情况下使用 ConfigureAwait(false) 更好吗？

对于库代码，我一般推荐ConfigureAwait(false)。 The same advice from nearly half a decade ago still applies today。但是，这里有一些缓解因素：

• 您的只有目标平台不提供SynchronizationContext。因此，只要您的代码仅在这些平台上运行，ConfigureAwait(false) 就不是必需的。
• ASP.NET Core 和EF Core teams no longer use ConfigureAwait(false)。但是，请注意 EF Core 团队确实提供了同步 API，因此人们的想法是首先不会阻塞他们的异步代码，因此缺少ConfigureAwait(false) 不会'在带有SynchronizationContext 的平台上使用时不会导致死锁。

因此，在您的情况下，您可以选择不来包含ConfigureAwait(false)。我会说这是一种有效的方法，因为您的库是 EFCore 的扩展，并且您提供同步和异步 API（就像 EFCore 一样）。请记住，这会在用户安装到具有SynchronizationContext 的平台（例如，经典的 ASP.NET）并阻塞您的异步代码的情况下打开死锁。但 EFCore 也有同样的限制。

顺便说一句，试试the boolean argument hack to prevent code duplication in your synchronous/asynchronous method pairs。

其次是从公开的方法中删除 async 关键字以用于示例中的场景是否明智？

没有。我不确定为什么会推荐这个。它可以防止最终用户检测到您是否在使用 async 关键字（编译器在 async 方法上放置了一个属性），但谁在乎呢？