我采取的观点:
a)用真正有用的业务约束来装饰 POCO。MVC 和 EF 等将为您检查一些重要的约束。
b)您可以并且应该向 POCO 添加对自定义注释或其他业务规则的检查。
如果有兴趣,请参阅示例:
c) DB 特定注释属于 EF fluent API。 如果它们是特定于数据库的,在我看来不属于 POCO。例如表名、模式、外键、关联映射、列重命名和忽略等。
d)错误消息和显示文本属于模型视图。或者至少从下面的 POCO 示例中抽象出来。我知道人们不喜欢加倍努力,并且会使用 POCO 作为模型视图,并且喜欢简单的文本和错误消息处理。但我更喜欢多语言和可配置的完整错误消息/文本处理解决方案。在我看来,在 POCO 上粘贴文本并不是最好的解决方案。
显然风格和建筑尺寸会影响选择,许多人会不同意 d) 我对此没有什么大问题。我拍摄了一张大图设计模式视图,并在有意义的地方进行了分离和抽象。
这里有一点 POCO 额外样本,没有注释,但它本来可以。我也看到了一些带有注释的好例子。这种错误风格可以在 MVC 中使用,并且在我看来比注释中的文本更好。
public class POCODemo : IValidatableObject //various ways to trigger this. Some for free
/// poco members .... bla bla
//Support Business rules...
public override IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
{
var vResult = base.Validate(validationContext).ToList();
if (Poco.property1 || poco.property is nasty or xyz issue)//psuedo code for your check
var memberList = new List<string> { "PropertyName1" };
var err = new ValidationResult("Some Text comes from your TEXTPOOL of choice that explains the error", memberList);
vResult.Add(err);
// }
}
return vResult;
}