Entity Framework Code First model separation from domain

Question

Entity Framework Code First best practice question?

Hi All I am using EF codeFirst 6 on an NTier app.

I have found that poco object that I am using to map to EF are really EntityFramework specific. Let me give you an example

If I want to add a property that is not related to EF in the object ,EF does not like it. I Read you can put the "NotMapped" attribute however it start making this object difficult to maintain .

Also there might be developers that are not familiar with EF and that will not understand the issue.

My question is it good practice to keep EF Entity Models separate and have a dto to convert to/from to a Domain Model where a developer can do what he likes with it without interferring with EF Model which is clearly a 1 to 1 with the tables in the database

Any Suggestions?

Answer 1

Your problem could be resolved by using the Fluent API approach instead of the Attribute-based (Annotations) approach. See Entity Framework Fluent API.

You would configure your entity mappings in the DBContext rather than in the entity classes.

From the above linked article:

Specifying Not to Map a CLR Property to a Column in the Database

The following example shows how to specify that a property on a CLR type is not mapped to a column in the database.

modelBuilder.Entity<Department>().Ignore(t => t.Budget);

that would mean "ignore the Bugdet property in the Department entity."