1

Regarding persistence of DomainModel using EntityFramework. I would like to validate following approach with experts in this area:

Leverage OnModelCreating to map or ignore navigation properties which are not needed. Unfortunately all these are specific to Code-First.

VS

Treat Model First POCO as DTO & using anti-corruption layer

We have huge investment in database designed using model first, in order to leverage DDD that leaves out only one path for us - leave POCO classes generated by designer alone & Domain classes separate. When ever needed do a manually mapping or use AutoMapper. Am I correct?

Secondly what would be best place to have this mapping, anti-corruption layer?

EDIT: We have > 250 tables in the schema, going through code-first I feel like losing the comprehension ability that designer providers, also model first I have complete authority once .SQL is generated. However in code first I have to live at the mercy of code-first migration to generate / update tables for me.

Abhijeet
  • 13,562
  • 26
  • 94
  • 175
  • Even though you can have POCO and domain classes separated using Automapper to _link_ both, I usually don't use POCO. I have my domain clean, without any reference to EF, therefore no OnModelCreating nor DataAnnotations in my domain. EF inside Infra/Data layer, referencing my Domain, and using my domain classes to generate database. In my application layer, I have simpler models which are exposed to app, representing domain classes which are mapped with Automapper. Please, read this [post](http://stackoverflow.com/questions/909264/ddd-anti-corruption-layer-how-to), I found it very interesting. – Alisson Reinaldo Silva Nov 29 '15 at 15:00
  • There's the "backing state object" approach, though I'm not a big fan of it and wouldn't recommend it for a greenfield app : https://vaughnvernon.co/?p=879 – guillaume31 Nov 30 '15 at 12:59

1 Answers1

1

I think database/designer first approaches don't work well with DDD. the reason being that class/model design is only part of your DDD design. another part is the methods that those classes/models provide. AFAIK you'll have a hard time implementing those with a designer first approach.

Also having a public default constructor is a common tradeoff people make to be able to map their model.

that said there are tools so you could create POCO objects based on your database. so your effort isn't waisted, even if you wanted switch to a POCO approach. Just future updates might be done in your POCO's first.

i think you need to ask yourself if the constraints you are imposing on yourself isn't keeping you from the solution you want, (using entity framework and having no public constructor)

If you keep your poco's separate from your model then yes the anti corruption layer is where they would live. They are just DTO's in that case.

Batavia
  • 2,497
  • 14
  • 16