asp.net mvc strongly typed helpers - should your render binding object be the same as your posting object?

Question

i see that asp.net mvc 2 has strongly typed helped and looking initially at the way it works i think maybe i am doing something wrong in asp.net mvc 1 in terms of data binding to render the view and post back to the controller.

I often have different objects for rendering the view and posting back to the controller. is this wrong ?? It seems natural as when rendering the view you often have a viewmodel that has lists for dropdowns, etc. but for your posting you only want the properties that are needed to post back.

for example, on the way in for rendering, my viewmodel might look like this

 public class PersonViewModel
 {
      public int Age;
      public string FIrst;
      public JobCategory[] JobCategories;
      public Sport[] Sports;
      public int NumberOfChildren;

 }

in this case, jobCategories and Sports is going to be used to populate a dropdown box. NumberOfchildren is going to just be html put in and i dont want it editable. When i want to post i only want to pass back a slim object with just the posted properties so i have another object

  public class PersonUpdater
 {
      public int Age;
      public string FIrst;
      public int JobCategoryId;
 }

these are the only properties that i need to pass back so my controller will look like this:

 public ActionResult Update(PersonUpdater personUpdater)
 {
      _repository.UpdateModel(personUpdater). 
 }

so, given the above, assuming the strongly typed helper methods (below) seem useful for the way in but then may cause issues on posting back to the server if you are referrring to different properties.

http://weblogs.asp.net/scottgu/archive/2010/01/10/asp-net-mvc-2-strongly-typed-html-helpers.aspx

any thoughts?

Answer 1

Real problem is - current accepted approach ignores SRP for view models a bit - edit form acts as input and output simultaneously.

People haven't accepted yet dividing view model into, as i call them, input view model and output view model (for many - even creating view model layer is too much). Therefore - Mvc2 currently lacks support for this (you aren't supposed to have strongly typed view that's not input and output at the same time) mainly because of vagueness and lack of broadly accepted approaches.

But i do think that there's a gain (ok... it's actually a trade off) in going deeper and separating view model into 2 of them. And i won't be surprised if this idea will evolve and eventually become widely accepted.

Actually - current approach even has a name - Thunderdome principle. And if guys like Jeremy D. Miller says this is correct, community won't bother and won't search for anything else.

---

From practical point of view - some of the issues you can mitigate through providing correct metadata (you might want to check out fluent model metadata provider).