interface - Async/Await in multi-layer C# applications -

i have multi-layered c# mvc4 web application in high-traffic scenario uses dependency injection various repositories. useful because testable, , in production can configure repositories specific controllers. controllers inherit asynccontroller, action methods return task<jsonresult> or task<actionresult> our server scale more users , solve dreaded thread starvation problem. repositories use web services, can use async/await provide scalability benefits. in other cases, may use unmanaged services can't threaded safely, in async/await provide no benefits. each repository implement of interface, irepository. in short, each implementation drastically different in way may data. configuration chosen @ deployment-time web.config changes , autofac modules.

what of recommended ways implement async/await in application such this? make pattern fit in existing application, have change interface return task<mybusinessobject>. but isn't more of implementation detail? provide 2 method stubs, getdata , getdataasync, me wouldn't allow flexibility have ioc frameworks autofac can swap out without having change code.

one of microsoft developers async/await has published blog post, "should expose asynchronous wrapper synchronous methods?" sort of goes problem. if async method isn't async (providing native i/o benefits) adds overhead. in other words, won't provide scalability benefits.

i how rest of community has tackled problem.

in situation, recommend making interfaces asynchronous:

public interface imyinterface {   task<tmyresult> getdataasync(); } 

for synchronous methods, can return task.fromresult:

public class myimplementation : imyinterface {   public task<tmyresult> getdataasync()   {     tmyresult ret = ...;     return task.fromresult(ret);   } } 

asynchronous methods can of course async , use await.

regarding implementation details, i'd "yes , no". ;) it's similar idisposable in regard. logically, implementation detail in sense shouldn't matter way it's implemented. it's not implementation detail in sense calling code needs handle differently. agree - logically - implementation detail, .net platform not sufficiently advanced treat such.

alternatively, can think of (which explanation give): async actual implementation detail, , when return task<t> instead of t, you're defining interface implementation may asynchronous.

i have series of blog posts address designing async "in large" (i.e., fitting async in oop rather allowing functional). address common problems such asynchronous initialization , ioc. it's 1 person's opinion, i'm not aware of other resources these kinds of problems.

p.s. don't need inherit asynccontroller anymore in mvc4. default controller handler automatically detect async methods return type (task or task<t>).