I like your approach but I’m using strongly-typed input helpers (Html.TextBoxFor, etc.). It was giving me issues because it was generating input names like “Data_Name” instead of “Name” so the values weren’t properly binding to the formModel in UpdateItem. The solution was to use the Bind attribute with the Prefix argument:

e.g. public ActionResult UpdateItem(int id, [Bind(Prefix="Data")] FormModel formModel)

Hope this helps anyone else who runs into the same issue.

I am pretty close to where you are on validation, in that the duplication of validation rules is a big code smell for DRY. But now I’m thinking of it like the domain model and form model. There is overlap, sure, but the models serve different purposes and can be tailored to that purpose. Form model validation is pretty much just input validation, with some business rules overlaping. But more complex validation belongs further down in the stack in your domain layer.

I used to think the ideal situation would be domain rules bubbling up to the UI layer so they can be validated there, but now I’m thinking this is just like having different models. It’s OK to have overlap if it’s a separate concern. Input validation and business rule validation are separate concerns to me.