。NET Core EF，何时避免异步数据库调用

Question

我目前正在编写一个简单的Web应用程序，该应用程序利用mssql数据库存储数据。现在，我尝试设置我的业务逻辑层，从而以最佳方式构造它。

目前，我所有的调用都是使用Linq进行的，实际上它们都不是异步的。我对异步编程还很陌生，通常好奇地知道，对于哪些查询我应该使用异步调用。

据我了解，使用异步数据库调用是有意义的，因为它释放了我的主线程上的内存，并且不会阻塞UI。同样，异步调用可以同时运行，这意味着可以同时完成更多事务。

但是，请考虑在我的上下文中异步添加多个实体，并使用SaveChangesAsync()方法得出我的上下文。那么在我的上下文中具有多个AddAsync()方法是否是多余的，因为SaveChangesAsync()仍将异步运行所有内容？

最后，根据我所阅读和看到的内容，很多人都喜欢使用异步数据库调用。那就是规则而不是例外。

如果是这样，在什么情况下我将避免异步数据库调用，在我的业务逻辑层中添加异步调用时应遵循哪些一般规则？

Answer 1

MVC中的异步是关于释放请求处理线程，以便它们可以响应其他请求。它不会使代码更快，而实际上会使它稍慢一些。当谈到线程时，很容易看到它在做什么，因为它移交给了工作线程。该异步方法完成后会发生什么取决于同步上下文。在大多数情况下，它将在辅助线程上恢复。

因此使用[thread＃]前缀：

[1] using(var context = new AppContext())
    {
[1]     var orders = await context.Orders
            .Where(x => x.CustomerId == customerId)
            .OrderBy(x => x.OrderDate)
            .ToListAsync();
[2]     foreach(var order in orders)
        {
            //...
        }
    }

await / async意味着C＃将移交给工作线程来执行代码，在这种情况下，将交给EF查询订单。它为该操作结束后将要执行的其余代码创建一个恢复点。同时，线程＃1结束，MVC可以使用它来响应其他请求。

考虑异步调用时应该考虑的是权衡执行操作所需的时间，以及创建恢复路径和恢复代码所需的时间/资源。异步调用在遇到相对少见的大型，昂贵的操作时会非常有用，这些操作可能占用响应线程，否则可能会在发起方等待时为请求提供服务。对于快速的常用操作，async可以减慢速度。因此，通常来说，如果一个操作要花费一两秒以上的时间才能运行，则非常适合async / await。对于快速查询，我默认将它们保持同步。