今天，我遇到了一些代码行，归结起来就是这样：
using (var db = new AppDbContext())
{
var foo = await db.Foos
.Where(m => m.Name == "BuzzBaz" )
.FirstAsync();
foo.Name = "Quxx";
db.SaveChanges();
}
请注意，选择查询是，async但对SaveChanges（）的调用不是。它是同步的！
这可能会引起任何问题吗？我应该重构它以使用db.SaveChangesAsync();，一切都很好吗？或者，也许只是打电话First()而不是FirstAsync()？也许它是无害的并且可能对整体系统性能有所帮助？
我找到了一些文档，使我认为完全删除async可能是一个不错的选择。https://docs.microsoft.com/zh-cn/ef/ef6/fundamentals/async
在大多数使用异步的应用程序中，没有明显的好处，甚至可能有害。在进行异步测试之前，请使用测试，概要分析和常识来衡量异步对您特定场景的影响。
您的代码是“正确的”，这意味着它没有根本的缺陷。
让我们分析发生了什么，以及我对它们的2美分：
在查询数据库（FirstAsync）时，使用await意味着将按顺序执行指令，但是不会阻塞线程（异步调用），并且可以将其用于其他用途。这可能是一件好事，如果这是服务器应用程序，则您可能希望线程在等待数据库响应时能够处理其他请求。
但是，使用非异步SaveChanges将阻塞线程。这本身不是错误，但是由于它也是对db的I / O操作，因此可能会在相当长的时间内阻塞线程。如果您也在await此处也使用了异步版本，则的确看起来会更加“一致” 。
那是个问题吗？这取决于。您的应用程序使用率很高吗？您的用户在重负载下是否有一些低反应性？那么在这种情况下，在保存时使用异步可能是潜在的改进。
否则，按照链接的MSDN文章上的建议，除非您知道它会产生影响，否则我的建议是不要太担心。
用法的混合本身不是问题。
就个人而言，我也会选择异步SaveChanges，以保持一致性并想象数据库写入是一些可能很慢的I / O操作。
如果它是桌面应用程序，只需确保您没有阻塞UI线程即可。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句