What's the benefit of using another model with Entity Framework in DDD

Question

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! :)

Answer 1

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.

Answer 2

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.