Question

I’m trying to learn ASPNET MVC. I’ve built a DbModel starting from DB structure so, under Models, I have the .edmx file that can be used to access data.

I’ve read that it could be good to have ViewModels classes to act between the View and the Model (useful also for single fields formatting) but I don’t’ understand if this is right and in which way it’s better to build them. If they reproduce classes in my model I believe it is a little bit redundant, isn’t it? If this is the right way, is there a way to generate automatically ViewModel classes?

Answer 1

A ViewModel in MVC is a model of your view. It is a property bag containing, usually of primitive types. It may seem redundant, but you are protecting yourself from future problems by decoupling your code.

As an example, given a Person object in your domain model:

public class Person
{
    public string FirstName {get; set;}     // John
    public string LastName {get; set;}      // Doe
    public DateTime Birthdate {get; set;}   // 01/01/1965
}

In your view, you may want to represent this in a view as a full name, age and birthday. Your ViewModel would be similar to:

public class PersonViewModel
{
    public string FullName {get; set;}     // John Doe
    public int Age {get; set;}             // 46
    public int Birthday {get; set;}        // January 1
}

Somewhere in your pipeline, you need to convert from domain model to the viewmodel. I have used either projection queries from the persistence layer or object-to-object mapping frameworks, such as AutoMapper.

By structuring your data this way, you can keep logic and formatting rules out of your view markup. By using a framework, such as AutoMapper, you can also standardize string formatting of dates and times, and do convention-based mappings.

Also, I generally advise having one ViewModel per View. If you need to share View/ViewModel structures or apply conditional view information, those should be separated into partial views.