Hi,

Just a quick thought: Controller Action Return Values.

 

Why return value of action is never used in ASP.NET MVC?
Why should we always use Response.Write or render a view to return data to client (in whatever format it is)?

Thoughts?

Cheers,
Dmitriy.

 Looking at the referenced article, this just seems to be setting view in an attribute on the controller (using the return value to pass data to it is much less significant).

This just seems to be a way of removing flexibility (each action could only have a single view).

With the current model, I can use the same action with multiple output formats (select view dynamically), this would be more difficult (and not so obvious) if the view were set with attributes. 

Nagir, it's a nice idea, especially when you're rendering some structured object that already exists in a completed state in memory (e.g. a System.Xml.XmlDocument). Of course even without using a return value and filter, it's still trivial to serialize such items to an output stream, perhaps with an extension method like xmlDoc.SerializeToResponse(IResponse response).

Response.Write is preferable if you're outputting a series of strings, because you're "streaming" the output instead of buffering it in memory first.

(Unless perhaps you returned an IEnumerable<string> via a "yield" statement, but that's just overcomplicating things.)

 Hi,

rjcox:

Tthis just seems to be setting view in an attribute on the controller.

That is the first thought. There are probably other ideas flying in the sky.

rjcox:

This just seems to be a way of removing flexibility (each action could only have a single view).

In some way yes. But let's think about a real application. I don't think that in most cases you want to render XML, JSON, HTML or whatever else it is from a single action.
You probably will have different actions to render different formats. The return value could be just a convenient feature like it is in ASP.NET Web Service methods (it's SOAP, but still developer returns an Object).

 

SteveSanderson:

Of course even without using a return value and filter, it's still trivial to serialize such items to an output stream

Of course. I just thought why to waste the return value :)
 

So it seems nobody really needs it. Well, let it be :)

Cheers,
Dmitriy.

nagir:

rjcox:

This just seems to be a way of removing flexibility (each action could only have a single view).

In some way yes. But let's think about a real application. I don't think that in most cases you want to render XML, JSON, HTML or whatever else it is from a single action.
You probably will have different actions to render different formats. The return value could be just a convenient feature like it is in ASP.NET Web Service methods (it's SOAP, but still developer returns an Object).

 

Perhaps not the best example. Another example of an action that needs to select different views would be a "New" or "Update" action that processes a data collection form. If the data is invalid it needs to present the same form (with error messages), if OK will move to a new view (list of entities or readonly view of the entity). 

Hi Richard,

rjcox:

Another example of an action that needs to select different views would be a "New" or "Update" action that processes a data collection form.

I see what you mean, but in this particular case New and Update are different actions and they can render different views and return different values as well as the same one.
And they should really render a view and not return a value.

Saying "action is returning a value" I meant the result of an action is a serialized Object (in some format) that is returned to a client. It has a little with the View itself.

Anyway, as we all already pointed, it is really so simple to "Jsonise" or "Xmlise" an object in the controller's code, so a return value just becomes non-practical.
Still, it should be useful some way :) Why should we lose this simple and basic feature of language :)

What I thought - is just a similar approach to .ASMX service methods.
There's another thought about return values. Most of actions end with RenderView call, even the view is chosen dynamically.
In most cases there is no code after the RenderView is called. This is exactly returning a value.

So why not return a ViewDetails as a return value?

Imaginary code:
  

public ViewData Find(string name)
{
    if (string.IsNullOrEmpty(name))
        return new InvalidArgumentView("name", name);
    var result = GetTheObjectsFromSomewhere(name);
    if (result.Count > 0)
        return new ViewData(result);
    else
        return new NoResultsView(name);
}

This will also (probably) allow much easier Views testing.

I don't know why, but I feel like we can benefit from return values :)

Cheers. 

Hi everyone,

We're thinking of doing something interesting with return values from action methods in the next preview of MVC. I can't say exactly what right now because we haven't figured out the design but we hope to have something to share with everyone fairly soon.

Thanks,

Eilon

nagir:

There's another thought about return values. Most of actions end with RenderView call, even the view is chosen dynamically.
In most cases there is no code after the RenderView is called. This is exactly returning a value.

So why not return a ViewDetails as a return value?

 

This makes more sense to me. Replacing the (as you note) final statement being a call to RenderView, with the return of an object that defines the view to render (i.e. some combination of {View Factory, View Name, View Data}.

The only capability this would loose is to be able to do something after RenderView (e.g. catch exception from the view). But I'm far from convinced that that is really much of a loss (and likely that would be better captured in the view factory (engine).
 

I think having a return value of type "ViewData" is a great idea.

1. For me, this would make testing a ton easier. For most tests I would no long need to mock/stub anything in order to test the controller action. This seems like a much cleaner solution.

2. It would make sure that you don't forget to make a call to "RenderView". It would be nicer if the compiler could to tell you that you'd forgetten to return a "ViewData" then to spend the time trying to figure out why your view isn't rendering.

3. I think it could help make the controller side of things a little more type specific. Right now you can use generics on the view side to type your data, but there's no equivilent on the controller side. It seems like this could provide a little more help with making sure you're not sending over the wrong data.

4. It could also help by not making every public method into a controller action. It would mean that only public methods that return "ViewData" are controller actions, which could save a little pain if you inadvertently make a method public.

Just my 2 cents

Herbrandson:

Just my 2 cents

I only got an idea and you evolved something that was messed somewhere in my brain :)

Agree with you an all points. At least on this stage.