Consider an Web app with UI(Controller), Business Layer & DataAccess layer.
Suppose to Get a List of Employees a call goes through all three layers, If we make it a Async call, does all the methods in these 3 layers in a call flow should we async to make it an efficient async call?
The entire chain, from the first method that calls async, to the last method that actually needs to do an asynchronous operation, needs to be async.
So in your case, the asynchronous operation is most likely to be in the data access layer. The DAL will be called from a business layer. And the BL will be called from your UI controller, thus all of them need to be async.
There's no reason to make methods arbitrary async, most likely you will have methods that don't call any other async methods, thus they don't need to be async themselves.
Another case when you should not have a method as async, is if you are just returning a task, without awaiting anything.
In short, yes, Async All the Way! Especially, do not use blocking code! Blocking code (mixed with async code) may cause various issues during run-time (e.g. deadlocks, difficulties with exceptions, etc.). See this MSDN Magazine Article.
In detail, only methods which have to await (i.e. waiting for completion, checking if canceled, checking if faulted, retrieving the result) should be async. Methods, which just return a Task or Task<T> without observing its Status should not be async in order to avoid the overhead. But eventually you have to await at least in your top layer code (e.g. UI) in order to retrieve the result and/or observe whether the Task has successfully ran to completion.
And, as a convention, you should always append "Async" to the name of async and/or Task-returning methods. See also docs and Stack Overflow.
