MVC 3 和 DRY 自定义验证答案

【问题标题】：MVC 3 and DRY custom validationMVC 3 和 DRY 自定义验证
【发布时间】：2011-02-26 21:14:41
【问题描述】：

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

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

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

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

或者说，重复自定义验证的权衡最终是否优于始终执行自定义验证服务器端引入的问题？

提前致谢。

【问题讨论】：

stackoverflow.com/search?q=[asp.net-mvc]+DRY+validation
@jfar - 在发布此内容之前，我实际上进行了相同的搜索，而且似乎大多数问题都集中在 UI 验证和业务验证的分离上。虽然我最初认为这与自定义客户端验证与自定义服务器端验证大多无关，但我可以看到它们如何（并且可能经常）相关，正如您在回答中提到的那样。

标签： asp.net-mvc validation asp.net-mvc-3 dry

【解决方案1】：

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

至于权衡 - 虽然违反了 DRY，但您获得了几件事：

立即向用户反馈（提高可用性）
在验证错误的情况下没有往返（服务器负载减少）

当然，除了违反 DRY 并让自己面临这些问题之外，您最终还会向客户端提供更大的有效负载（额外的 javascript）。

没有人能告诉您这些折衷是否值得 - 您需要确定适合您的应用程序、用户和客户端的方法。

【讨论】：

是的，我绝对理解其中的权衡，但似乎延迟和负载仍然是最小的。我不知道，也许我低估了它。我很想看看对影响进行的基准测试。
@Jerad - 如果您有很多数千个并发用户？您希望服务器上的负载最小。当然，如果你只有一个用户并且你的服务器速度很快，那么重复这样的逻辑可能就有点过头了。
是的，就像我说的，我知道会有影响，而且你拥有的并发用户越多，它就越复杂。但我目前运行一个有 10 年历史的 ASP 网站，在某些情况下，它会回传到服务器并获取一个全新的页面，只是为了进行验证（我知道这很糟糕，但我确实说它是 10-岁）。虽然性能肯定会受益于更多的客户端验证，但它目前是完全有能力的。我想我会很高兴开始使用 DRY 验证，然后在需要时通过客户端验证来扩展它。
@Jerad - 就像我说的，这取决于不同的事情。如果您的应用程序的性能还可以，并且您不希望增加的工作量会改变这种情况，为什么要改变呢？如果它没有坏，请不要修复它；）

【解决方案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 有足够的信用额度进行购买有很大不同，并且应该区别对待。

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

【讨论】：

所以换句话说，如果我试图在需要更复杂逻辑和/或访问数据库的客户端上进行验证，我应该质疑这是否甚至属于客户端（或表示层) 开头——这是你的意思吗？
@Jerad Rose - 在某种程度上。取决于您的应用程序。比利不能买股票，因为他没有钱对我来说非常重要，也许不应该被“黑客”（不是真的，太苛刻的词，但你明白了）进入 MVC 应用程序的 UI 或 V .我不知道这是否太含糊，但测试比利是否可以购买股票与如果他没有足够的钱就不允许比利购买股票大不相同。那有意义吗？ ;)
我接受这个作为我的答案，因为它让我想起了[Remote]，我需要重新考虑我的担忧。

【解决方案3】：

我并不真正同意您对在这种情况下违反 DRY 原则的担忧，但看起来其他几个人已经讨论过这个问题。

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

How To: Implement Remote Validation in MVC3

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

【讨论】：