我怀疑如果我在数据访问层中使用异步功能是否有任何性能提升，如下所示:
public async Task<IEnumerable<TrnApplicant>> GetAllMemberApplicantsAsync(String webReferenceNumber)
{
using (var context = new OnlineDataContext())
{
var applicant = await Task.Run(() => context.Applicants.First(
app => app.RefNo.Equals(webReferenceNumber, StringComparison.OrdinalIgnoreCase)) );
return GetApplicantsInGroup(applicant.ApplicantsGroupId);
}
}
另外，如果不是，什么时候更有意义？
最佳答案
考虑一下。
您调用某人，请他们为您做某事。在他们这样做的同时，您在线上等待，等待他们说“完成”。这是同步工作。在他们完成工作之前称他们为“障碍”，然后您可以返回到您正在做的任何事情，之后。
另一种异步方式是让您调用电话，而不是等待电话挂断，并在他们工作时做其他事情。一旦他们给你回电话，说“完成了”，你就回去做任何你需要他们的结果做的事情。
现在，如果您在等待期间无事可做，绝对不会有任何性能提升，反而会适得其反。让对方给您回电话的开销反而会增加要做的工作总量。
那么通过上面对异步工作的描述，您的代码在等待数据访问层完成其工作时是否有任何可以做的事情？
如果不是，则不会，不会有性能提升。
如果是，则可能会提高性能。
现在，说了这么多，我阅读了我的答案下方的评论，然后我更仔细地重新阅读了您的代码，我相信您并没有真正利用这里的适当异步代码。
最好的方法是使用某种能够正确执行异步 I/O 的系统或代码。您的代码调用 Task.Run ，这实际上与让另一个人坐在电话前等待您一样。
例如，考虑 SqlCommand ，这可能是与数据库对话的实际代码，它有两个有趣的方法:
现在，如果您调用第一个，在使用 Task.Run 创建的线程上，你实际上仍在阻塞，你只是要求别人为你做。
然而，第二个是我上面描述的。
所以在你的特殊情况下，我会尽量避免使用 Task.Run .现在，根据服务器的负载，这样做可能是有利的，但如果可以的话，我会改用底层对象的异步方法来正确地完成它。 p>
关于c# - 在数据访问层中使用异步是否有任何性能提升？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26214408/