I have an asp.net mvc “edit” page which allows the user to make edits to the parent entity, and then also “create” child entities on the same page. Note: I’m making these data transfer objects up.
public class CustomerViewModel
{
public int Id { get; set; }
public Byte[] Timestamp { get; set; }
public string CustomerName { get; set; }
public etc..
public CustomerOrderCreateViewModel CustomerOrderCreateViewModel { get; set; }
}
In my view I have two html form’s. One for Customer “edit” Http Posts, and the other for CustomerOrder “create” Http Posts. In the view page, I load the CustomerOrder “create” form in using:
<div id="CustomerOrderCreate">
@Html.Partial("Vendor/_CustomerOrderCreatePartial", Model.CustomerOrderCreateViewModel)
</div>
The CustomerOrder html form action posts to a different controller HttpPost ActionResult than the Customer “edit” Action Result.
My concern is this, on the CustomerOrder controller, in the HttpPost ActionResult
[HttpPost]
public ActionResult Create(CustomerOrderCreateViewModel vm)
{
if (!ModelState.IsValid)
{
return [What Do I Return Here]
}
...[Persist to database code]...
}
I don’t know what to return if the model state isn’t valid. Right now it’s not a problem, because jquery unobtrusive validation handles validation on the client. But what if I need more complex validation (ie: the server needs to handle the validation).
Well, it is a problem now because you can’t trust jQuery to do your validation for you. You can’t trust anything on the client because it’s not really under your control. You have to validate everything on the server, even if you’re doing it client-side just to be slick.
What you call a ViewModel
is what I like to call the EditModel
. That is, a flattened representation of the Model
that can be in an invalid state. Your server needs to be able to translate from a ViewModel
DTO to the Model
and back again, but it also needs to have the validation logic to check the ViewModel
before it performs the conversion.
So when you submit the DTO to the server, you always get back another ViewModel
. In the case where it was a success, you get back your new ViewModel
with the edits applied, or if it was unsuccessful maybe you get back a ViewModel
that has validation errors. The page has to display those validation errors. Those errors have to be in the ViewModel
either as fields, or as a collection of validation messages that get displayed in a pop-down or something.