The latest EF tutorial that goes through how to use EF 6 with MVC 5 seems to lean towards using asych calls to the database like:
Department department = await db.Departments.FindAsync(id);
Is this the new standard/best practice?
I'm not sure what the benefit is for this style of development with ASP.NET MVC.
Can someone comment on this pattern, is this the new standard that MS is promoting?
In order to decide whether to go async or sync, compare the benefits and costs:
Choose async with ASP.NET if you are calling high-latency services. A web-service is likely to be high latency. An OLTP database is almost always low-latency.
Choose async if your application benefits from very high levels of concurrency (100+). Most applications do not have such high levels, or their back-end services would not sustain such an amount of load. No point in making the web app scale but overload the back-end. All systems in the call chain must benefit from a high degree of concurrency in order for async to be beneficial.
Typical high-latency services (good cases for async):
Typical low-latency services (good cases for sync):
These are categorized by the typical case. All of these can be in the opposite category as well.
You can mix sync and async in the same app. Use async when it is at its sweet spot.
So why are Microsoft and the Entity Framework team promoting async usage? Here comes the subjective part of this answer: It might be Microsoft internal policy. They might anticipate EF usage in client apps (for which async is great). Or, they don't realize that async database calls are pretty much almost always a waste of developer's time without benefits. Most people don't realize this because async is the way to go these days.
On ASP.NET, you should use asynchronous APIs for anything I/O-related, including database access and web service calls.
async allows ASP.NET to make maximum use of the thread pool, resulting in non-trivial scalability benefits.