为什么EF 6教程使用异步调用？
通过如何使用EF 6与MVC 5的最新EF教程似乎倾向于使用asych调用数据库，如：
Department department = await db.Departments.FindAsync(id); 这是新标准还是最佳做法？
我不确定这种ASP.NET MVC开发的好处是什么。
有人能评论这个模式吗，这是MS推广的新标准吗？
为了决定是异步还是同步，比较好处和成本：
异步：
- 几乎不会用async耗尽线程池（情况必须是极端的）
- 几乎任意级别的并发（并发请求和操作）
- 每个线程节省1MB的内存
- 由于
SynchronizationContext安全的请求内并发性 - 由于减少了操作系统调度开销，可以提高高负载情况下的低两位数百分比。 也就是说，几乎没有生产应用程序在高CPU负载下，因为如果它是接近不可用（在负载峰值的情况下，应用程序开始下降请求）。
同步：
- 更简单的代码：await使得99％的情况（几乎）与同步代码一样简单。 也就是说，堆栈溢出每天有超过10个异步问题说不同的语言。 当您偏离简单路径时会出现边缘情况。 另外，当使用传统的库时，例如，要求你给他们一个同步的回调。
- 减少编码和调试工作
- Profiler友好（您可以简介应用程序或只是暂停调试器，看看应用程序正在做什么，不可能与异步。
- 与遗留代码和库完美交互
如果您正在调用高延迟服务，请使用ASP.NET选择异步。 Web服务可能是高延迟。 OLTP数据库几乎总是低延迟的。
如果您的应用程序受益于非常高的并发性（100+），请选择异步。 大多数应用程序没有这么高的级别，或者他们的后端服务不能承受这么多的负载。 使网络应用程序缩放，但超过后端没有意义。 调用链中的所有系统必须从高度的并发性中受益，才能使异步变得有益。
典型的高延迟服务（异步的好例子）：
- 网页服务
- 等待（如睡眠）
- 节流（
SemaphoreSlim，…） - 一些云服务（Azure）
- 对数据库的长时间运行查询（例如报告或ETL）
典型的低延迟服务（同步的好例子）：
- 数据库调用：大多数OLTP查询的延迟较低，因为您可以假定数据库服务器不会被重载。 没有必要在其上抛出100个并发查询。 不要让他们完成任何更快。
- 文件系统：与数据库相同。
这些按典型案例分类。 所有这些都可以在相反的类别。
你可以在同一个应用程序混合同步和异步。 当它在最佳位置时使用异步。
那么为什么微软和实体框架团队促进异步使用？ 这里回答这个答案的主观部分：这可能是我微软的内部政策。 他们可能会预期在客户端应用程序（异步是伟大的）的EF使用情况。 或者，他们没有意识到，异步数据库调用几乎总是浪费开发者时间而没有好处。 大多数人没有意识到这一点，因为异步是最近走的路。
在ASP.NET上，您应该使用异步API来处理与I / O相关的任何事情，包括数据库访问和Web服务调用。
使用async允许ASP.NET最大限度地利用线程池，从而获得不平凡的可伸缩性优势。
理想情况下，任何涉及一段时间的等待应该是异步完成的。 数据库查询通常必须调用远程服务器，发送查询，然后等待服务器响应结果。 这使得它成为异步的主要候选者，因为整个“等待服务器响应”部分是一个变量，你不能在你的应用程序中考虑。
使用异步允许Web服务器在您的代码正在等待异步操作完成时重新使用当前线程来处理其他Web请求。 完成后，线程将返回给您的应用程序继续处理。 如果您运行同步，那么当您在等待数据库或任何其他长时间运行的进程时，线程会死锁，并且不可用于Web服务器的池。 如果这样做的话，Web服务器可能会用完可用线程，并且必须开始排队进一步请求。 异步通过释放线程来解决这个问题，当他们只是在等待某些东西时，增加了您的Web服务器可以处理的潜在负载。
