Entity Framework: Separation of concerns

Question

Hi there,

I'm using the EF and wondering how other people are separating the Data Context from the Entities.

Basically i need one tier to access the Data Context (the model object) to call SaveChanges() etc.. and other tiers need access to the Entity type itself. So for example if a method returned an Entity and i called that method from my UI, then I would have to reference the Model from the UI and that's not good.

is there a way to have the entity types in one project and have the Data Context in another project?

i guess another way would be to create Interfaces for each entity and put the interfaces in another project which other tiers could reference. But this is a lot of maintenance and a pain in the ass

Answer 1

Create a domain model off your entities, which basically mirrors the fields/properties you have. This can be in a totally separate project, separate layer.

To map between the two - the EF entities and the domain model classes - I would use a tool like AutoMapper to ease the assignments between two separate but almost identical classes.

That way you get a clean, nice separation, and you save yourself a lot of boring typing!

Answer 2

Hi billy!

In my opinion, although this is indeed a pain in the ass, the interfaces are the better way to go. You will really achieve loose-coupling.

With interfaces, you will be able later to change totally your entity layer and your UI won't even notice. Interfaces were created for that purpose, clear separation and isolation.

People always tend to find interfaces boring and time wasting. But the time you save by ignoring them, you will pay it later, I tell you !

Marc_s gave you a great answer too (hey, that's marc_s!), but less pure in my opinion.
You can also go for POCO entity objects, but coupling starts here.