Should I use separate models for domain and EF?

Question

Scenario: I am writing a program that handles report generation.

I have the report stored in a database, mapped to an EF model. There are some non-database fields (i.e. some fields are auto-calculated based on other fields that ARE in the db). Would it make sense to have one class that solely maps to the DB, and another class that takes that information and additionally has the other calculating fields?

i.e. a sample class to interact with the codefirst database would be

public class Report{
    public int CategoryOneSeverity {get; set;}
    public int CategoryTwoSeverity {get;set;}
    public string Title {get;set;}
}

Would it make sense to make another class, like:

public class ReportModel{
    public int CategoryOneSeverity;
    public int CategoryTwoSeverity;
    public string Title;

    public int RiskRating{
        get{ return CategoryOneSeverity + CategoryTwoSeverity; }
    }
}    

Or should the RiskRating property be in the EF model.

Answer 1

Yes, I absolutely believe you should have different classes to model your domain than your DB. Unless your application is extremely trivial, if you try to map your domain objects directly, you invariably have to change them to match what you need your data structure to be, and possibly expose things you don't want to expose. Think of it as a violation of the Single Responsibility principle; your class has two reasons to change if you make it your domain object and map it directly. One is in response to changing business requirements, the other is in response to changing data storage schema.

Answer 2

"Would it make sense to have one class that solely maps to the DB, and another class that takes that information and additionally has the other calculating fields?"

Most likely yes. Usually I would create a new class suffixed with "ViewModel" such as HumanResourcesReportViewModel if my entity class was HumanResourcesReport.

There's lots of variations on how to use ViewModels, and we could get into a pedantic debate about terminology, but conceptually, take your entity and create a new class with that data plus whatever additional information you need to process the report. In this case the report generation is in a way the View of the MVC model, so I don't think it's offensive to call the class holding the data a ViewModel.

Answer 3

Are you using Code First or DB First?

You can have auto calculated fields in your model, which are not mapped to fields in the database.

It also depends on your architecture. If you're using DB first, refreshing your EF model would update your EF classes, losing your mapped fields. In the DB-First scenario, an alternative would be to use the EF model class as your base class and inherit from it for your report class.

public class ReportModel
{
    public int CategoryOneSeverity;
    public int CategoryTwoSeverity;
    public string Title;
}   

public class ReportClass : ReportModel
{
    public int RiskRating
    { 
        get { return CategoryOneSeverity + CategoryTwoSeverity; }
    }
}