non POCO ORM in decoupled application design
I need to use LLBLGEN or EF4. I know that it is possible to use poco with EF4, however I need to use general approach. So my aim is to implement non poco orm and decouple it from domain. It means that I can't use DAL entities in Domain as it will be coupled, hence I want to use repositories. If I use some DTO between DAL and Domain then I'll lose DAL entities internal state and have to map and remap DTO to entity. Thats why I want to write additional interface f开发者_StackOverflowor each entity that will have just properties declarations. Repositories will use these interfaces and DAL entities won't lose its state. To create new object in DAL I will use abstract factory.
Cons: no need to map remap DTO in DAL Entity, DAL entities don't lose its state. Pros: need to write additional interfaces and track if entity is updated and sync this modifications with interface, write additional code to implement abstract factory (however it is not difficult).
I personally think that it worth it. Could you share your opinion about this solution?
You sound confused. Do you want to create a domain model? Then do so. Build it DRY. Do not create separate property interfaces. The domain model holds the state, so the DAL state is derived. The mapping should be nearly automatic (all the simple mappings) by introspecting the domain model.
精彩评论