Returning data with viewmodel in POST request

I have a view model like such:

public class MyViewMode开发者_开发技巧l
{
    public string Name { get; set; }
    public List<Purchases> Purchases { get; set; }
}

This viewmodel is sent to a view that allows the user to edit the name property. The Purchases property is used only to create a dropdown box for it:

<%: Html.DropDownListFor(t => t.Name, new SelectList(Model.Purchases, "Value", "Text")) %></p>

This works fine.

However, when I perform server-side validation and then return to the View, I'm getting an object null reference error because the Purchases property is now set to null. I'm guessing this is because when the form is submitted because the Purchases property isn't bound to any editable control, it isn't being passed back with the viewmodel.

How can I prevent this happening? I want to send back the List to be send back with the Post request always.

You don't need to send back the list. If validation fails then simply rebuild the view model from scratch. One of the main selling points of MVC is how well it works in a stateless environment. Web Forms used ViewState to do this kind of thing, I don't think you want to replicate this kind of functionality though.

I like to have two overloaded Action methods for this (both with the same name but different method signatures). One with an [HttpGet()] attribute and the other with an [HttpPost()]. If your model is found to be invalid on the POST then simply return the "GET" method (NOTE: you'll need to to pass in any parameters required to rebuild the view).

When I say return, I mean:

return MyGetAction();

and not a Redirect to the GET action.

If the model is valid then you could/should perform a RedirectToAction() to a GET Action (this means if the user hits the refresh button it won't submit the form again, this is called the Post/Redirect/Get (PRG) pattern)

You'd have to create a hidden input for each of the elements in the list in addition to the select list. Having said, that I think caching the results of the query on the server is a better way to handle repopulating the list if you don't want to perform the query again. There's no sense in sending the data back across the wire if the server can just hang on to it. Personally, I wouldn't even bother with the caching unless it proved to be a performance bottleneck. Just populate the model selection list from the DB.

<% for (int i = 0; i < Model.Purchases.Length; ++i) { %>
   <%: Html.Hidden( string.Format( "Purchases[{0}]", i ), Model.Purchases[i] ) %>
<% } %>

Lee Gunn is spot on. To make the answer a little more concrete, it is very common to re-build non-scalar values in the event ModelState is not valid. This can be done by simply returning the [HttpGet] version in your Controller. However, you could simply re-build the purchases collection manually. It's up to you.

[HttpGet]
public ActionResult MyView(string name)
{
    //get entity and build up a view model
    var entity = _myDb.GetEntity(name);
    MyViewModel vm = AutoMapper.Map<Entity, MyViewModel>(entity);

    return vm;
}

[HttpPost]
public ActionResult MyView(MyViewModel vm)
{
    If(!ModelState.IsValid)
    {
        //here is one way of doing it
        return MyView("");

        //OR

        vm.Purchases = GetSomePurchasesBro();
        return View(vm);
    }

    //continue on persisting and doing the Post Redirect Get 
}

P.S. Calling

return MyView("");

can be replaced with

return MyView(vm.Name);

Both will do the same thing (provided you're using the Html Helper Extensions, i.e. Html.TextBoxFor(x=>x.Name))

Defaut model binding looks in the ModelState for attemptedValues when rendering Html. This is described here by Steve Sanderson.