asp.net-mvc - MVC 3 和 DRY 自定义验证

Question

除非我遗漏了一些东西(这很有可能)，在我看来自定义验证总是违反 DRY。在我看到的所有示例中，即使使用 MVC 3 引入了全新的 Unobtrusive Client Validation，我们也必须为我们的服务器端验证创建 .NET 代码，并为客户端验证创建 jQuery(或 JavaScript 代码)。

我知道没有像 .NET 到 jQuery 转换器这样的东西可以促进 DRY 服务器/客户端验证，我想这将是实现真正的 DRY 验证的唯一方法，它可以在服务器端和客户端都工作。

但是我对始终在服务器上执行自定义验证感到非常满意。传递到自定义验证所需的数据(在我的情况下)通常仅限于一两个字段，并且服务器端逻辑通常非常快，即使它必须访问数据库。

是否没有 OOTB 机制用于使用属性连接自定义验证，然后让您的客户端验证使用 Ajax 执行验证服务器端并响应客户端？或者，有没有人想出这样的解决方案？

或者，最终，重复自定义验证的权衡比总是执行自定义验证服务器端引入的问题要好？

提前致谢。

Answer 1

OOTB:http://msdn.microsoft.com/en-us/library/system.web.mvc.remoteattribute(v=vs.98).aspx

您并没有真正在这里验证 DRY。 DRY 的概念比简单的代码重复更微妙。存在可接受的权衡，尤其是在考虑耦合问题时。

当人们问这个问题时，如果你四处搜索的话，这个问题是很常见的，我通常会向他们提到 bounded concepts 的 DDD 概念。 .使用 [Remote]并且在验证时强制使用 DRY 往往会将大量关注点集中在一个地方并合并多个层的职责。业务逻辑与持久性和数据完整性逻辑(非空值)。

@Darin Dmitrov 在他对这个确切问题的许多回答中都说得很好。验证必填字段是否已填写与确保 Sally 有足够的信用来进行购买有很大不同，应该以不同的方式对待。

客户端验证最适合用于基本问题，并且不会因更繁重的操作而过载。客户端验证对可用性的影响非常小。发布表单并等待刷新并没有什么“不可用”的地方。它更流畅，但不会影响您的应用程序的成功。