I'm new to domain driven design but want to learn it and use it for a new application. I will be using Entity Framework for data access.
The basic layout so far is:
ASP.NET MVC and other clients (mobile devices etc.)
|
Webservices
|
Domain Model (Services, Repositories, Aggregates, Entities and Value Objects)
|
Data Access Layer (Entity Framework)
|
Data Storage (SQL Server)
What is the best way to transfer data between the data access layer and the domain model? I'm thinking that the entities in the domain model are POCO objects and that they should be mapped to/from the Entity Framework objects. Is this a good solution?
If so:
How and where should such a mapping occur? (Domain Model Layer or Data Access Layer)
Where and how should I query Entity Framework (ie. return a list based on a search)?
ANDREY YEMELYANOV has done a masters thesis on this exact subject:
http://gupea.ub.gu.se/dspace/bitstream/2077/10462/1/gupea_2077_10462_1.pdf
This will get much easier with the release of EF 4, which supports POCO objects.
In the meantime you could try using automapper to map between domain and EF objects, see: http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/01/22/automapper-the-object-object-mapper.aspx
I'm thinking that the entities in the domain model are POCO objects and that they should be mapped to/from the Entity Framework objects. Is this a good solution?
I think it is.
This is something that we have done quite successfully, although in my case in the Java world. Our domain classes contain the majority of the business logic. Each has a reference to a thin data entity object and delegates the getting and setting of the persistent properties to the data entity.