I'm migrating a fairly large ASPNET MVC app from .NET 4.5 to .NET 6 and in the process I'm refactoring the architecture which currently uses Entity Framework 4 with all business logic and data access in the MVC controllers. The new architecture consists of a service layer which is called by the web app's controllers, the service layer in turn retrieving data from MS SQL via a separate repository layer which uses Dapper for the ORM stuff.

I've been looking at using Dapper's async methods, especially for the cases where I'm calling a stored procedure to add or update data for several entities (calling Dapper with a list of said POCO entities to execute against the specified sproc) so I'm thinking that some efficiency gains could be made using Dapper's async query method in the repository layer. However, because the repository method that's calling Dapper is not async, then there's still blocking which would seem to make calling Dapper's async methods pointless.

Unless I'm misunderstanding it?

CodePudding user response：

... make calling Dapper's async methods pointless.

Yes, that is correct. Using async on the repository will, by itself, gain you nothing.

The profit comes from connecting your async Action method through an unbroken async/await chain to the async I/O. That allows asp.net to handle the workload with fewer threads.

So for scalability you ought to refactor the service layer to Task<> methods all the way.

If that's not feasible then async methods will get you nothing. Just use the non-async versions, starting in the Controller.