实体框架数据注释是否对DDD和关注点分离不利？

Question

I've been working quite som time now to learn how to implement DDD, IoC and ensure there is a separation of concerns in my application. I'm also trying to get in to the way of Test First Development.

Somehow Entity Framework gives med some trouble. I have a domain project that keeps my domain objects (many of them POCO classes now, but with some behavior). It's legacy code, and I try to refactor it, but MVC realies heavily on Dataannotations for validation.

The datavalidation-attributes is set on the domain objects, which ties them to the entity framework. Most instructional videos and documentation on EF also uses a lot of attributes on the domain objects.

So I wonder if this is really a good thing?

I like the idea of many of the attributes, but the consequence of putting them on the domian objects makes me feel that entity framework is the core of the application and not the domain objects.

Do you have any tips on solving this, or is this how it should be?

UPDATE:

The suggested answers below led me to this post answered by Ladislav Mrnka

To me that probably sounds like the best way to go if it solves my problem. He also points out the same problem I have with the attributes in the domain layer.

Answer 1

使用Code First Fluent API验证会更好吗？

Answer 2

Some attributes are relevant to EF and MVC - attributes that describe your class. A required field, minimum and maximum lengths, etc... If you really want to separate everything, I'd keep these attributes on your domain objects, put database stuff (foreign keys, etc...) in FluentAPI and MVC stuff (display names, etc...) on the view model.

If MVC 4 happens to support FluentAPI (I'm using MVC 3, which doesn't, don't know about 4), you should definitely use it.