public Task<Bar> GetBar(string fooId)
{
return Task.Run(() =>
{
var fooService = new FooService();
var bar = fooService.GetBar(fooId);
return bar;
});
}
public Task<Bar> GetBar(string fooId)
{
var fooService = new FooService();
var bar = fooService.GetBar(fooId);
return Task.FromResult(bar)
}
public async Task<Bar> GetBar(string fooId)
{
return await Task.Run(() =>
{
var fooService = new FooService();
var bar = fooService.GetBar(fooId);
return bar;
});
}
我的猜测是,第一种是正确的做事方式,并且在您尝试从返回的Task获取结果之前,代码不会执行.
第三种有点像第二种？代码是在调用时执行的,Task.Run的结果是返回？在这种情况下,这个函数会有点愚蠢吗？
我是对的还是离开的？
解决方法
话虽如此,这里有不同之处：
#1
第一个变体(它返回一个Task< Bar>直接通过Task.Run创建)是“最纯粹的”,即使它从API的角度来看没有多大意义.您允许Task.Run在线程池上安排给定的工作并返回Task< Bar>表示对调用者的异步操作的完成.
#2
第二种方法(利用Task.FromResult)不是异步的.它同步执行,就像常规方法调用一样.结果只包含在一个完整的Task< Bar>中.实例.
#3
这是第一个更复杂的版本.你正在实现类似于#1的结果,但是有额外的,不必要的,甚至有点危险的等待.这个值得更详细地看一下.
async / await非常适合链接异步操作,通过将表示异步工作的多个任务组合到一个单元中(任务).它可以帮助您按正确的顺序进行操作,为您提供异步操作之间丰富的控制流,并确保在正确的线程上发生事情.
但是,上述情况都不会对您的方案有任何好处,因为您只有一个任务.因此,没有必要让编译器生成一个状态机,只是为了完成Task.Run已经完成的工作.
设计糟糕的异步方法也很危险.通过在等待的任务上不使用ConfigureAwait(false),您无意中引入了SynchronizationContext捕获,从而导致性能下降并引入死锁风险,从而无益.
如果您的来电者决定阻止您的任务< Bar>在具有SynchronizationContext(即Win Forms,WPF和可能的ASP.NET)的环境中,通过GetBar(fooId).Wait()或GetBar(fooId).Result,由于here讨论的原因,它们将陷入僵局.
