7

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

adam
  • 93
  • 1
  • 3
  • 1
    If you're using Code-First EF, then the POCOs are really your domain model – Didaxis Nov 07 '11 at 22:18
  • Yea that's what I understood, but how would you reference these objects across layers, specifically infrastructure to domain/model? – adam Nov 07 '11 at 22:41
  • 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: http://www.asp.net/entity-framework/tutorials/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application – Andrei Drynov Nov 08 '11 at 00:49

1 Answers1

8

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.

BornToCode
  • 9,495
  • 9
  • 66
  • 83
Magnus Backeus
  • 2,242
  • 17
  • 24
  • Thanks Magnus, this is the approach I have taken - separate assembly referencing both the domain and infrastructure layers! Having played with it yesterday, code-first seems like a nice feature of EF! – adam Nov 09 '11 at 07:36
  • Good Luck adam. Feel free to ask or discuss other DDD issue directly to me. I'm Always interesting how people see problems in different ways... – Magnus Backeus Nov 10 '11 at 12:49
  • Thanks Magnus - I do have a few more questions, what's the best way to contact you? – adam Nov 14 '11 at 16:51
  • Use my email magnus.backeus@gmail.com – Magnus Backeus Nov 15 '11 at 07:24
  • Hey Magnus, Thanks for nice practical suggestion. I am also planning to follow the same. My Project is big and divided in modules. Each module have it's own Domain project and it will have single project with DataContext/Mapping class. Now each domain project requires to refer each other as there could be relationship between these. and It might cause Circular References.My related SO question is:- http://stackoverflow.com/questions/11502929/ddd-modules-and-ef-code-first -- Thanks. – Anand Jul 16 '12 at 11:02