Excellent article. I'm guilty of the Synchronous Async/Await section. I will use the Task.WhenAll method from now on. I have one question.
I've been taught in past companies that I worked on that you aways should use async/await all the way down from controller to database. Is it worth using async/await Even if the method does only one thing?
public async Task<MyModel> DoOneThing() {
return await myService.GettingMyModelFromDatabase();
}
Stephen Cleary has series about async. Check out this article to find full answer for your question.
TL;DR:
Don't elide by default. Use the async and await for natural, easy-to-read code.
Do consider eliding when the method is just a passthrough or overload.
Remember that eliding async changes semantic of your code (e.g. there are some pitfalls with exceptions and stack traces).
As for me, I almost always don't elide async because I had really hard-tracking issues because of eliding async several times. So, my rule is to elide async only when you should do it (e.g. in performance critical places).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Excellent article. I'm guilty of the Synchronous Async/Await section. I will use the Task.WhenAll method from now on. I have one question.
I've been taught in past companies that I worked on that you aways should use async/await all the way down from controller to database. Is it worth using async/await Even if the method does only one thing?
Stephen Cleary has series about
async. Check out this article to find full answer for your question.TL;DR:
asyncandawaitfor natural, easy-to-read code.asyncchanges semantic of your code (e.g. there are some pitfalls with exceptions and stack traces).As for me, I almost always don't elide
asyncbecause I had really hard-tracking issues because of elidingasyncseveral times. So, my rule is to elideasynconly when you should do it (e.g. in performance critical places).