displaying View models with a large number of properties - asp.net-mvc

Question

I've had a read through Jimmy Bogards post from a whiel back on how they do view models, in my own project I've come across a few places where there is quite a lot of information that needs to displayed at one time on the screen such as a form that needs to be filled out where all fields are shown at once.
So our view models would look something like
public class FormViewModel
{
public string field1 {get;set;}
public int field2 {get;set;}
public DateTime field3 {get;set;}
public string field4 {get;set;}
...snip
public string field50 {get;set;}
}
Now the forms do have sections so we could introduce a bit of structure into the viewmodels like this:
public class FormViewModelSection1
{
public string field1 {get;set;}
public int field2 {get;set;}
}
public class FormViewModelSection2
{
public DateTime field3 {get;set;}
public string field4 {get;set;}
}
and then the main viewmodel becomes
public class FormViewModel
{
public FormViewModelSection1 {get;set;}
public FormViewModelSection2 {get;set;}
}
so we would return the more complex viewmodel to a main view that basically just delegates each of its sections out to be rendered through a renderpartial like
<div>
My form
<%: Html.RenderPartial("soemascx", Model.FormViewModelSection1)%>
</div>
or maybe use an editorfor to render the contents.
My question is, is the "recomposing" of the viewmodel a valid thing to do or is it undoing some of the benefits that are provided by making a view model so flat.

Answer 1

I'd say there's no right answer to your question. It all up to usability and functionality. Maybe even personal coding style.
Meaning as long is it is
working (displaying, posting back, validating etc)
serves the purpose
understandable by others (read maintainable)
consider it to be good solution. If you'd ask about what I'd do: I'd go with one flat class well decorated (data annotations) for names and validation, and structures supporting visual representation (like lists for combo boxes, enums (or whatever you comfortable with) for radio buttons.
As a note, I had some bad experience with hierarchies of view models (inheritance) - was working really poorly with validation (inherited data annotations don't work as expected with view model inheritance).
So to answer your specific question - no, you not doing anything wrong ... its up to you how to do it.
Hope this helps.

Answer 2

I personally don't separate my ViewModels into child ViewModels unless it's for something like a "UserControl" type thing, e.g. A small form on the side of the web page would be a separate ViewModel and the main page ViewModel will reference it.
But generally, I have a BaseViewModel which is an abstract class that has all the shared fields (like pagetitle etc), then I have a ViewModel for the View itself which inherits BaseViewModel. example:
public abstract class BaseViewModel
{
public string PageTitle { get; set; }
public string MetaDescription { get; set; }
public string MetaKeywords { get; set; }
}
I might have a small signup form that i use in a few of my pages. So i'll create a separate ViewModel for this small form. One benefit of separating this out into it's own object is that when the user submits the form, I can pass in the specific SignupViewModel object instead of the main page with all it's entities.
public sealed class SignupViewModel
{
[Required]
public string YourName { get; set; }
[Required]
public string YourEmail { get; set; }
}
Then for an basic web page with the above usercontrol:
public sealed class PageViewModel : BaseViewModel
{
public string PageID { get; set; }
public string PageContents { get; set; }
public SignupViewModel UserSignupForm { get; set; }
}
I suppose there's a number of different ways to tackle the same thing, but this above is how I do it.