Must ASP.NET MVC Controller Methods Return ActionResult?

Question

Being new to ASP.NET MVC, I've been wondering about the signature of Controller methods. In all the examples I've seen, they always seem to return ActionResult, even if they actually return a ViewResult instance or similar.

Here's a commonly seen example:

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

In such a case, wouldn't it make more sense to declare the method as public ViewResult Index(), and get stronger type support?

Experimentation indicates that this works, so it seems possible.

I do realize that there may be situations where the polymorphism is desired (e.g. if you want to redirect only in certain situations, but show a view in other situations), but if the method always returns a view, I'd find a ViewResult more desirable.

In terms of future compatibility, ActionResult obviously provides a more robust signature, but if one controls the entire code base, it's always possible to change a method's signature to a more general return type if that should become necessary in the future.

Are the any other considerations that I'm not aware of, or should I just go ahead and declare my controller methods with specific return types?

Answer 1

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."

Answer 2

Always return the most accurate type you can return. So you should return a ViewResult when the action always shows a view. I would only use ActionResult when you return in ViewResult in some cases (invalid posted data) or a RedirectToRouteResult in other cases.

With some advanced actionfilter/executing scenario's, you can even return totally different things that have nothing to do with ActionResult.

Answer 3

[Partial answer]: You don't always return ActionResult, no. Here's a quick view of some other results you can return: http://msdn.microsoft.com/en-us/library/dd410269%28v=vs.98%29.aspx

Maybe that'll help a little. Good luck!

Answer 4

Yes, you can define your action like: public ViewResult Index(). But sometimes your action can return different results (it is impossible without declaring result as base ActionResult class). For example:

public ActionResult Show()
{
    ...

    if(Request.IsAjaxRequest())
    {
        return PartialView(...);
    }

    return View(...);
}

or:

public ActionResult Show()
{
    ...

    try
    {
        ...
    }
    catch(Exception)
    {
        return RedirectToAction(...);
    }

    return View(...);
}

Answer 5

ActionResult is the base class for the various return types. So your action must return an ActionResult or a class derived from it in order to work. Common ones are ViewResult, JsonResult, etc.

Answer 6

Yep I have Sanderson's book, and I liked that part about being specific, as that was something vexing me when I was looking at other controller action examples. My philosophy even b4 learning MVC was that since functions (methods that return a value) should be treated as if you were declaring a variable/be substitutable in context for a variable/ref of the same type, be specific about the type, as you would if declaring a var (think of it as wanting to avoiding defnining all your variables as type "Object" in an app - more robust, but you lose some design-time checking and type safety). Facilitates a controller unit test for the correct return type as well.

For related reference, check out Listkov's Substitution Principle (the "L" in "SOLID") also.