Domain Driven Design and Entity Framework 4.1 (code-first)

7
votes

I am currently learning the domain driven design approach to development and using the .NET Domain Driven Design with C# book by Tim McCarthy as a guide.

The book is really helpful but I'm becoming a bit unstuck when it comes to using the entity framework, in particular the code-first approach available in 4.1.

Based on the example in the book, the layered architecture approach should mean the infrastructure layer can't see the model/domain one.

So what's the best approach to mapping my domain poco's in the db context classes which (I assume) should sit in the infrastructure layer, without contravening the layered approach?

There's a good chance I'm completely wrong with my thinking so please let me know as I'm still learning!

Many thanks :)

Adam

1
c#entity-frameworkdomain-driven-design
If you're using Code-First EF, then the POCOs are really your domain model – Didaxis
Yea that's what I understood, but how would you reference these objects across layers, specifically infrastructure to domain/model? – adam
My models are in a class library, and the business library references that DLL. I'd recommend reading some articles on Unit of Work and Repository patterns online - they work well with POCO. Here: asp.net/entity-framework/tutorials/… – AFD

1 Answers

8
votes

Well most ORM's today, like EF 4.1 and Nhibernate (fluent Nhibenrate addon) can describe mappings from POCO to Db context through mapping classes. These mapping classes should best be placed in an infrastructural database project, maybe together with ORM session specific classes.

Then your POCO domain classes should be placed in a Domain project that shouldn't have any references to other components or projects. BUT the infrastructural database project should reference the domain so that your mapping classes can descibe how POCO's should be loaded from a persisted state.

Use a lot of Dependency injection together with a good and solid IoC framework (Windsor Castle...). This will help you to loosen things up a little bit. Its better to depend on an abstraction/interface rather than an implementation.

Here is the basics http://www.infoq.com/articles/ddd-in-practice

But good thing you decided to go for the Code First approach. I really recommend that approach if you have the option. But sometimes when old legacy systems interfere, things aren't that easy.