MVC在哪里放置需要db调用的验证

Question

在mvc app中采用这个简单的常见场景：

当用户注册用户名时，需要是唯一的。

现在我已经阅读了很多关于项目结构，域驱动设计，验证，mvc等的内容，我对我的逻辑层感到高兴：域（模型，核心），域服务，控制器和视图。我可以确保例如通过向我的属性添加验证属性，用户名少于10个字符。失败将通过服务层冒回到控制器中并进入视图。

但是对于这个简单的场景我仍然坚持调用堆栈的最佳解决方案 - 并且测试得很好，因为这个验证需要调用db来检查所有其他用户名。

对我来说，这仍然是User模型的验证问题。我真的希望能够创建自定义验证属性，以便在设置此属性时，检查持久性以确保唯一性。

哇哦！一个域对象直接调用db？我不确定这是件坏事。我可以让城堡将IRespositories注入到域中，所以没有紧密耦合，毕竟它是定义数据接口的域。

有没有人对此有任何经验/意见？

Answer 1

  

对我来说，这仍然是用户模型的验证问题。

错了......肯定不是。用户不应该了解兄弟姐妹。

如果User是实体（肯定不是），验证唯一性是包含聚合根的责任。

如果它是聚合根，则没有太多选项（因为“没有任何东西”是聚合根，它们是全局的） - 我使用了存储库，尽管它们不应该具有域逻辑。但话又说回来 - 我不认为这种唯一性验证为really valuable（参见“所有规则都不相同”）。

Answer 2

最后，我坚持认为应该在域中处理这种行为，而且似乎并不孤单。

最新版本的S＃arp架构包含一个新的类Validation属性HasUniqueDomainSignature，与Property属性DomainSignature结合使用。在NHibernate.Vaidator上调用IsValid时，Common Service Locator用于定位当前的NHibernate会话并引用持久性。

Here's对它的讨论。

Answer 3

如果您要使用DDD路径，也许您应该考虑使用命令启动域更改。然后域对象不需要对它们进行验证：您可以在命令上执行所有必需的验证。

对于某些框架提供的基于属性的验证（如asp.net mvc），我真的很讨厌。您的域模型不应该是他们关注的问题。域对象应始终处于有效状态，并自行维护其不变量。