CODEWITHSUNDEEP
c#asp.netasp.net-mvcasp.net-mvc-4
gtu
gtu

Reputation: 966

Deriving a database model for view model in ASP.MVC

I am creating some view models for my ASP MVC web app. I created "code first" models for database. Is it a good way to derive view models from database models?

Example database model:

public class Project
{
    [Key]
    public int Id { get; set; }
    public int? CustomerId { get; set; }   
    public int TypeId { get; set; }   
    public string Number { get; set; }  
    public string Name { get; set; }
}

View model:

public class ViewModelProject : Project
{
    [NotMapped]
    public DateTime? Start { get; set; }
    [NotMapped]
    public DateTime? End { get; set; }
    [NotMapped]
    public string Manager { get; set; }
}

Is this the right way or is it completely false?

EDIT (subquestion): I have some very simple database models like ProjectType, which only contains i.e. two properties. Should I also fragment those models in model view or can I make it that way: Simple database model:

public class ProjectType
{
    [Key]        
    public int Id { get; set; }    
    public string Name { get; set; }
    public int? Code { get; set; } 
}

Can I use it like so:

public class ProjectVM
{
    public string Name { get; set; }
    public int Number { get; set; }
    public ProjectType Type { get; set; }
}

Or does it have to be fragmented like so:

public class ProjectVM

    {
        public string Name { get; set; }
        public int Number { get; set; }
        public string Type { get; set; }
        public int TypeCode { get; set; }
    }

Upvotes: 0

Views: 369

Answers (1)

Sefe
Sefe

Reputation: 14017

I would not recommend doing it this way. I (and many others) have tried it and it doesn't work well. You will inadvertedly run into troubles, since an MVC model has to be tailored to the view and what you get from the DB rarely fits. Sure, you can hammer it into place, but the code quickly gets messy and store-related and UI code starts to mangle together. This even shows in your example, since you have to put the NotMappedAttribute (which is related to data storage), to ViewModelProject (a class at UI level).

There are many other examples to show this problem, but an especially good one I find when you want to serialize a model object to JSON and send it to a JavaScript client. The JSON serializer takes the values of all public properties and adds them to the JSON. If you want to exclude a property, you have to mark it with a ScriptIgnoreAttribute, which you would also have to apply to the base class, which breaks separation between UI and store-related code.

The better way to go is to keep the staorage model and the MVC model separated and to map the data from one to the other (there are already pre-existing frameworks that help you with that, such as Automapper). This comes with additional advantages, for example better testability, since you are now not dependent on a specific data store to create model instances.

Upvotes: 4

Related Questions