Trying to understand the new async/await pattern, I have one question which I can’t find an answer to, namely if I should decorate my methods with async, if I intend to call those methods from other async functions, or just return Tasks where appropriate?
In other words, which of these classes A, B or C is best, and why?
class A<T>
{
public async Task<T> foo1() //Should be consumed
{
return await foo2();
}
public async Task<T> foo2() //Could be consumed
{
return await foo3();
}
private async Task<T> foo3() //Private
{
return await Task.Run(...);
}
}
class B<T>
{
public async Task<T> foo1() //Should be consumed
{
return await foo2();
}
public async Task<T> foo2() //Could be consumed
{
return await foo3();
}
private Task<T> foo3() //Private
{
return Task.Run(...);
}
}
class C<T>
{
public async Task<T> foo1() //Should be consumed
{
return await foo2();
}
public Task<T> foo2() //Could be consumed
{
return foo3();
}
private Task<T> foo3() //Private
{
return Task.Run(...);
}
}
It seems redundant to overdecorate methods so I naturally lean toward C, but at the same time it feels somewhat awkward to work with Task<T> unless you use the await keyword.
Both versions work effectively the same, the only difference is that when you use
awaithere, you get some performance penalty (because the state machine must be set up and a continuation will most likely be used).So, it comes down to a tradeoff: Do you want your methods to be somewhat more efficient at the cost of being slightly less readable? Or are you willing to sacrifice performance for readability?
Usually, I would advise you to go for readability first and only focus on performance if profiling tells you it’s worth it. But in this case, I think the increase in readability is small, so I would probably not use
await.Also note that your class
Cstill doesn’t go far enough:foo1()also doesn’t needawait.