Are classes generated by Entity Framework database classes or business classes?

Question

I have a three tier app with a class library as the Infrastructure Layer, which contains an Entity Framework data model (database first).

Entity Framework creates entities under the Model.tt folder. These classes are populated with data from the database.

In the past I would map the classes created by Entity Framework (in the data project) to classes in the Domain project e.g. Infrastructure.dbApplication was mapped to Domain.Application.

My reading is telling me that I should be using the classes contained in .tt as the domain classes i.e. add domain methods to the classes generated by Entity Framework. However, this would mean that the domain classes would be contained in the Infrastructure project, wouldn't it? Is is possible to relocate the classes generated by Entity framework to the Domain project? Am I missing something fundamental here?

Answer 1

You can relocate the entity classes by creating a new item in your Domain project: DbContext EF 6.x Generator (not sure of the name and you might have to install a plugin to get this item in the list, also exists for EF 5.x).

Once you have created this new item, you have to edit it to set the path of your EDMX at the very begining of the file. In my project for example it is:

const string inputFile = @"..\..\DAL.Impl\GlobalSales\Mapping\GlobalSalesContext.edmx";

You will also need to edit the DbContext.tt file to add the right using on top of the generated class. At each change you've done on the EDMX, you also will have to right click the generator and click: "Run custom tool" to generate the new classes.

That being said, is it a good practice? As you can see that's what I have done in my project. As long as you do not have EF specific annotations or stuff like that in the generated entity classes, I would said that it is acceptable.

If you need to change your ORM, you can just keep the generated classes and remove all the EF stuff (.tt files, etc) and the rest of your application will work the same. But that's opinion based.

Answer 2

You should move your model to a different project. That is good practice. I don't quite get it what you meant by "moving to to Domain project" Normally entity framework generated classes are used as a domain model. No need for creating "different" domain model from this. This model should be use only near to database operations, whereas web(window) application should use only DTO (Domain transfer objects)

I don't know if you use it or not - but this is a nice tool allowing for recreating model from the database :

https://marketplace.visualstudio.com/items?itemName=SimonHughes.EntityFrameworkReversePOCOGenerator

This allows to store model in classes (instead of EDMX) Someone refers to it as "code first" but there is a misunderstanding. One can use this tool to create model and still be on "database first" This is done simply to omit using EDMX as a model definition.

Answer 3

I think in the true sense it is a Data Model - not a Domain Model. Although people talk about having the Entity Framework Model as a domain concept, I don't see how you can easily retro fit Value objects such as say amount which would be represented in the true domain sense as such:

public class CustomerTransaction
{
    public int Id { get; set; }
    public string TransactionNumber { get; set; }
    public Amount Amount { get; set; }
}

public class Amount
{
     public decimal Value { get; }
     public Currency Currency { get; }
}

As opposed to a more incorrect data model approach:

public class CustomerTransaction
{
    public int Id { get; set; }
    public string TransactionNumber { get; set; }
    public int CurrencyType { get; set; }
    public decimal Amount { get; set; }
}

Yes, the example is anaemic, but only interested in properties for clarity sake - not behaviour. You will need to change visibility of properties, whether you need default constructor on the "business/data object" for starters.

So in the domain sense, Amount is a value object on a Customer Transaction - which I am assuming as an entity in the example.

So how would this translate to database mappings via Entity Framework. There might be away to hold the above in a single CustomerTransaction table as the flat structure in the data model, but my way would to be add an additional repository around it and map out to the data structures.

Udi Dahan has some good information on DDD and ORM in the true sense. I thought somewhere he talked about DDD and ORM having the Data Model instance as a private field in the domain object but I might be wrong.

Also, that data model suffers from Primitive Obsession (I think Fowler coined it in his Refactoring book - although it Is in his book) Jimmy Bogard talks about that here.

Check out Udi Dahan stuff.