Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
add comment

3 Answers

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
So, my model might have properties pointing to different physical tables behind the scenes? for example; ContactModel, shouldn't be a 1 to 1 match to the database table dbo.Contact in every case? –  MVCylon Jun 17 '11 at 14:32
    
Your model represents an item from the real world, not a database table. How the data in the model is persisted is a completely unrelated question. In most cases you will probably split these two into model classes and data access classes (which form a layer of their own), and then the separation gets even clearer. So the answer is, yes, it could use any number of tables. –  wolfgangsz Jun 17 '11 at 14:40
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.