MVC 3和DRY自定义验证

Question

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

据我所知，没有.NET-to-jQuery转换器可以促进DRY服务器/客户端验证，我想这将是真正的DRY验证的唯一方法，它既适用于服务器端，也适用于客户端。

但我完全满足于始终在服务器上执行自定义验证。传递到自定义验证所需的数据（在我的情况下）通常限于一个或两个字段，服务器端逻辑通常非常快，即使它必须访问数据库。

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

或者最后，重复自定义验证的权衡取决于总是执行自定义验证服务器端所引入的问题？

提前致谢。

Answer 1

AFAIK，没有任何OOTB（开箱即用）。

至于权衡 - 虽然违反DRY，你会得到几件事：

• 立即向用户反馈（提高了可用性）
• 如果验证错误（服务器上的负载较少），则不会进行循环跳闸

当然，除了违反DRY并打开自己的问题之外，你最终还会向客户端提供更大的负载（额外的javascript）。

没有人可以告诉您这些权衡是否值得 - 您需要决定什么是适合您的应用程序，用户和客户。

Answer 2

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有足够的信用来进行购买有很大不同，应该区别对待。

客户端验证最适合用于基本问题，而不会因为繁重的操作而过载。客户验证对可用性的影响非常小。关于发布表单并等待刷新没有“无法使用”。它更流畅，但没有任何东西可以决定你应用程序的成功与否。

Answer 3

在这种情况下，我并没有真正分享您对违反DRY原则的担忧，但看起来其他人已经讨论了这一点。

但是，您的想法听起来很像MVC 3中添加的新远程验证功能：

How To: Implement Remote Validation in MVC3

另一方面，没有什么能阻止您在客户端执行所有内置的简单检查，并且仅在回发到服务器时执行所有重度自定义验证。