Take the 2-minute tour ×

When looking at some application designs for DDD, I see that the objectgenerated from the entity framework are only used to access the data store. Once the data is loaded it's mapped to another POCO object defined in the model of the application.

Is this just good design and is done for the sake of design? Or is there some added value for redefining the entire application model and not use the generated objects? If so if any of you have done some research on that already, what are the pros and cons of using EF objects in every layer of your application vs having a different model?

MVC Storefront is an example of an application that does that (even though it uses LINQ to SQL) but it's the same idea.

Thanks! :)

share|improve this question
add comment

2 Answers

Separation of concerns. POCO allow you to remove any dependency on EF within your domain model. Unlikely but if you hit a technical brick wall with EF there will be less impact when switching out to a different ORM/DAL.

share|improve this answer
Is this the only advantage, not to undermine it but I was thinking from a design feature POV, the way using repositories allow for a more testable application? –  Hatim Sep 13 '10 at 11:41
Hatim - Technically you are correct and although they generally both go together in achieving separation and therefore testability. The repository pattern is independent of POCO. –  Darren Lewis Sep 13 '10 at 19:13
Daz, I just gave the repository pattern as an example of an architectural feature that is great for testability. But I find it a bit too much to add a whole model just in case the technology we use doesn't pan out. seems too much work for nothing. –  Hatim Sep 14 '10 at 9:45
"Add a whole model" is nothing more than running the T4 template. You don't have to write any additional code. –  Darren Lewis Sep 17 '10 at 9:39
add comment

The technique is called DTO (Data Transfer Objects) and it totally disconnects the data access mechanisms from any other parts of the system.

From my experience, using the entity objects (or even better, POCOs in EF4 which have many of the advantages of DTOs) is quite alright for small and possibly even medium projects, but of course maintainability over the long term is better with POCOs and/or DTOs.

share|improve this answer
add comment

Your Answer


