Art Of Programming

musings by Dmytrii Nagirniak

MVC Controller Action Return Values

Just a quick thought about actions in MVC (MonoRail or ASP.NET MVC).

Often there is a need to return JSON or XML result from an action.
Common solution is rendering specific view or some kind of "Response.Write"-ing; so the code usually looks like this:

   1:          public void FindProducts(string query)
   2:          {
   3:              IProductList products = GetProducts(query);
   4:              PropertyBag.Add("products", products);
   6:              RenderView("ProductsJsonResult");
   7:          }
   9:          // Or this way
  11:          public void FindProducts(string query)
  12:          {
  13:              IProductList products = GetProducts(query);
  14:              Response.Write( JsonSerialize(products) );
  15:          }

It seems for me that the returning value is much more logical. Why don’t we ever use return values and mark actions with void
…the code would be looking much better:

   1:          [ResultConverter(JsonConverter)]
   2:          public IProductList FindProducts(string query)
   3:          {
   4:              return GetProducts(query);
   5:          }


If the ResultConverter attribute is not applied, than Json or Xml should be used by default.

I like this stuff. I believe it’s not that hard to introduce such a feature in both MonoRail and ASP.NET MVC.

I don’t know why nobody has asked about it before. Maybe I just haven’t seen or don’t know, maybe even it’s already implemented and I’m not aware of it.

Anyway ASP.NET already supports it in Web Services (different things to compare, but still). I personally don’t like to write Web Service just to allow some page to get data from it (yes, that’s about WebForms). And would not prefer web service for HTML pages over controller actions.


UPDATE (19/03/2008):

Returning (serialising) an object is a very simple procedure and in many cases applying attribute to serialise Object becomes non-practical. But I have another idea of using a return value.

Most of actions end with RenderView call, even if the view is chosen dynamically.
In most cases there is no code after the RenderView is called and the result of a common action is a View. This is exactly returning a value.

So why not return a ViewDetails as a return value?

Imaginary code:

public ViewDetails Find(string name)
    if (string.IsNullOrEmpty(name))
        return new InvalidArgumentView("name", name);
    var result = GetTheObjectsFromSomewhere(name);
    if (result.Count > 0)
        return new SearchResultView(result);
        return new NoResultsView(name);

It seems like some some stuff is going to be implemented with return values…


TV Digital
Hello. This post is likeable, and your blog is very interesting, congratulations :-). I will add in my blogroll =). If possible gives a last there on my blog, it is about the TV Digital, I hope you enjoy. The address is A hug.