Models should match table structure, Viewmodels match how the data need to be displayed?

Question

I have a database table with many columns, that I want to display over several pages, similar to a turbo tax style information collection form. With only 1 or 2 items per page.

Is it right to create 1 model, then a viewModel with only certain properties per ViewModel for each section I want to create in this workflow?

Answer 1

The whole idea of .NET MVC is that.

You have your models to work in your data layer (Entity Framework, nHibernate or any other thing...) which represent your data, hence the simmilarity with your tables. On the other hand, you'll have to define ways to present that data to your users, which is done in views, and to do so, you create your ViewModels. They may look alike but they're not the same.

Take for instance an example where you have a User model, a Group model where every user has a group. Your data models will be User and Group, but your ViewModel to create a user should include a list of the available groups, much like this:

public class RegisterViewModel
{
    public string UserName { get; set; }
    public string Password { get; set; }
    public string PasswordConfirmation { get; set; }

    public IEnumerable<Group> AvailableGroups { get; set; }
    public int SelectedGroup { get; set; }
}

In one ViewModel you are mixing two models, keep in mind that they can be much more.

Answer 2

Certianly if that is how you want your site to work. One of the advantages of MVC is you can design your model independant of how your want your program to operate. Your model is your data. Your view is your UI and your controller of ViewModel is the logic layer that translates the two.

Answer 3

In general, yes, that is a valid approach.

Be careful, though, to clearly distinguish between the model in your MVC environment and the storage of the data in a database. How you store your data should be almost completely independent from the model. and the number of columns in your database table should not have an impact on the design of your model, other than that this particular model happens to use this particular table for storage of some or all of its data. But at the same time you could have other models using the same table or one model using multiple tables.

The design of your model should be based on the problem you are trying to solve and not the underlying storage mechanism.