Any issues with always using ASP.NET MVC AsyncController instead of Controller? - asp.net-mvc

Question

We have a series of ASP.NET MVC controllers that all inherit from a single base controller (that inherits from the Controller class). We are now looking at creating some asynchronous actions, and was wondering if we'd run into any trouble if we just changed the base controller to inherit from AsyncController instead of Controller (meaning all of our controllers would inherit from AsyncController).

Answer 1

Jess,
In my opinion, you'll do no harm as the asynch functionality is only called into play when you follow the conventions of:
public class PortalController : AsyncController
{
public void NewsAsync(string city)
{
AsyncManager.OutstandingOperations.Increment();
NewsService newsService = new NewsService();
newsService.GetHeadlinesCompleted += (sender, e) =>
{
AsyncManager.Parameters["headlines"] = e.Value;
AsyncManager.OutstandingOperations.Decrement();
};
newsService.GetHeadlinesAsync(city);
}
public ActionResult NewsCompleted(string[] headlines)
{
return View("News", new ViewStringModel
{
NewsHeadlines = headlines
});
}
}
the convention being the addition of the News*Async* and the News*Completed* portions in the naming.
see:
async controllers in asp.net mvc 2
Observe that the controller class now derives from AsyncController rather than Controller. In addition, the News action method has been split into methods named NewsAsync and NewsCompleted, which are analagous to the Begin and End methods in asynchronous pages. Logically, the controller still exposes a single action method named News. But physically, the method implementation has been broken up using a variation on the async pattern used throughout the .NET framework.
If you don't change anything in your inherited controller code, then no async activty will be initiated. However, as stated by Robert above (or below maybe :-)), you could decorate the actions on a needs must basis to keep the intention clear, tho', i personally think the convention should show that up clearly.
certainly worthy of debate.

Answer 2

MVC 4 doesn't have an asynch controller - see the source:
namespace System.Web.Mvc
{
// Controller now supports asynchronous operations.
// This class only exists
// a) for backwards compat for callers that derive from it,
// b) ActionMethodSelector can detect it to bind to ActionAsync/ActionCompleted patterns.
public abstract class AsyncController : Controller
{
}
}
See my tutorial Using Asynchronous Methods in ASP.NET MVC 4

Answer 3

If you set a breakpoint in your Action method and observe the callstack (with Show External code enabled), you will see that there are several additional steps required to invoke a synchronous action residing in an AsyncController vs. in a standard Controller. Namely the AsyncControllerActionInvoker invokes Begin/End style methods ending with BeginInvokeSynchronousActionMethod. I don't know how much overhead these extra calls contribute, but it is something to be aware of before you blindly extend all your controllers from AsyncController even where no Async actions exist.

Answer 4

You should be fine doing that since AsyncController already inherits from Controller.
See here for more information
The remarks on that page are quite useful for determining whether you're doing the right thing by inheriting from AsyncController and offers a nice guide to keep you on track.

Answer 5

The use of an Async Controller depends on whether you want to wait for any particular task or step to complete before going on to the next task. The problem is akin to buying something from Amazon before the money from your paycheck hits your checking account.
For typical web applications, I would say this is not advisable. The web server is already very parallel, so the only advantage would be speeding up responsiveness to the user. For many operations this benefit would be negligible.
I would reserve the Async Controllers for long-running processes in the background, where it is impractical to wait for the task to complete before returning the web page back to the user's control.
NOTE: If you have a copy of a .NET disassembler (or the ASP.NET MVC source), you can open up the AsyncController class and have a look at the code. That should give you a pretty good idea whether or not you can use the AsyncController as an ordinary Controller.
The article I linked to below says this: "Controllers that derive from AsyncController enable ASP.NET to process asynchronous requests, and they can still service synchronous action methods."
http://msdn.microsoft.com/en-us/library/ee728598.aspx