开发者

Entity Framework: Separation of concerns

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开发者_JS百科 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


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.


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!

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜