Why does most MVC sample controller code return ActionResult?

Question

Just wondering why almost every controller method I see in sample MVC code returns ActionResult, even if it's obvious that the code can only return one type of result. I understand there are certain instances where it's warranted because you may return, say a RedirectResult or a ViewResult depending on the logic, but that's not the case for most of the methods I've seen.

Isn't it tantamount to having a return type of 'object' on a method? Why not just specify JsonResult, or FileResult or ViewResult as the return type? Is there a benefit I'm not seeing to settting the return type to ActionResult on every controller method?

Classic example:

public ActionResult Index()
{
    return View();
}

Why does this seem to be the norm instead of this:

public ViewResult Index()
{
    return View();
}

EDIT: So far all of the responses except for one have indicated that ActionResult is just more generic. I know that much. :) Why is this accepted practice on a controller method though, and not anywhere else? You don't just return the highest level-base classes of a type that you can on a normal method, you attempt to return the most specific type you can usually. What makes controller methods so different that bloggers and "sample code writers" (yes, I made that term up) would just resort to returning ActionResult?

Answer 1

quoted verbatim from an accepted answer here on SO. makes sense to me:

Must ASP.NET MVC Controller Methods Return ActionResult?

You can absolutely use specific return types, even though most examples on the web seems to return the ActionResult. The only time I would return the ActionResult class is when different paths of the action method returns different subtypes.

Steven Sanderson also recommends returning specific types in his book Pro ASP.NET MVC Framework. Take a look at the quote below:

"This action method specifically declares that it returns an instance of ViewResult. It would work just the same if instead the method return type was ActionResult (the base class for all action results). In fact, some ASP.NET MVC programmers declare all their action methods as returning a nonspecific ActionResult, even if they know for sure that it will always return one particular subclass. However, it's a well-established principle in object-oriented programming that methods should return the most specific type they can (as well as accepting the most general parameter types they can). Following this principle maximizes convenience and flexibility for code that calls your method, such as your unit tests."

see also:

http://www.bengtbe.com/blog/post/2009/07/01/Use-specific-return-types-in-your-ASPNET-MVC-action-methods.aspx

Answer 2

My guess would be that ActionResult gets returned rather than a more specific result simply because there's no need to make the code more specific.

Using a more generic type keeps things more flexible.

Keep in mind that changing the return type may not be an issue in the Web Application project, but it would also cause you to change all your Unit Tests in the test project as well.

Answer 3

ScottGu did it prob 4 the same reason; it's just easier to show an example. The subject of the demo often dictates the ode quality you see; if it's just for exmaples, they'll generally throw something to gether just to illustrate a point (they made it easy on themselves to write/test the example on their end b4 publishing, and just left it that way when posting; I've done this). As far as best practices; about HTML and JS (essentially) "not caring" as much about types, dont let issues with JavaScript (like type weakness) leak thru/infect your own honed good coding style. Use the specific type whenerver possible. Plus, ur JS code is also prob expecting a JSON result anyway (if it's coded using typing best-practices), and is aomsthing that code can test for as well, so wouldn't want to tie the JS code's hands there if it's trying to do the right thing on types where it can. True that in some cases, the adverse effects are more/less pronounced than in others (like returning to a less type-safe lang), it's just a better programming habit to be consistent about. In general, doing this kind of thing usu results in some kind of type casting/coersion to get back to the more specific object's capabilities you want to use upon return (which more than likely won't be available in a baser object - if it always is, then your type is too specific/should be the base anyway). Casting is inherently ugly/evil; deriving types at run time will always get you in trouble (why the practice has been discouraged/benes of static/strong typing/safety extolled for decades). Let the consumer/maintainer of your code also be able to discern thru metainfo (hovering over the method, etc.) what the function is actually doing/returning. And in fact, it's better for unit testing, as this is a condition that can be tested (as the excerpt from Steven Sanderson's book alludes to). And did I catch a guy using not wanting to hold a build as a reason for being weakly typed? Really?

Answer 4

Only when you're not sure what the return type will be b/c of logic inside the controller you should use a general return type. otherwise - use specific (it is considered BETTER programming).

I don't know why people use ActionResult in samples, but I've seen many things in samples that I might not agree - take what good and leave the rest there....

IMHO - You should use ViewResult when you know this is the only returned object you use and not ActionResults.

Answer 5

It's maybe because ActionResult is the highest object that a view can handle.

ActionResult

ViewResult

System.Object
  System.Web.Mvc.ActionResult
    System.Web.Mvc.ViewResultBase
      System.Web.Mvc.ViewResult

For me, each XXXResult is dedicated to a specific use. If you do not need specific...

Answer 6

I think the real reason is that the auto-generated code in the MVC templates start you out with an ActionResult, and people just follow the pattern. Since many people don't unit test their controller actions, they don't consume the results in a type-safe way that would make this a pain point.