MVC 3 和 DRY 自定义验证
除非我遗漏了一些东西（这很有可能），否则在我看来，自定义验证总是违反 DRY 的。在我见过的所有示例中，即使使用 MVC 3 引入的全新非侵入式客户端验证，我们也必须为服务器端验证创建 .NET 代码，并为客户端验证创建 jQuery（或 JavaScript 代码）。
据我所知，没有像 .NET 到 jQuery 转换器这样的东西可以促进 DRY 服务器/客户端验证，我想这将是实现真正的 DRY 验证在服务器端和客户端都有效的唯一方法。
但我非常满意始终在服务器上执行自定义验证。传递到自定义验证（在我的例子中）所需的数据通常仅限于一两个字段，并且服务器端逻辑通常非常快，即使它必须访问数据库也是如此。
是否没有 OOTB 机制来使用属性连接自定义验证，然后让客户端验证使用 Ajax 来执行服务器端验证并响应客户端？或者，有人想出了这样的解决方案吗？
或者说，最终重复自定义验证的权衡是否比始终执行自定义验证服务器端引入的问题更好？
提前致谢。
Unless I'm missing something (which is very possible), it seems to me that custom validation has always violated DRY. In all the examples I've seen, even with the brand new Unobtrusive Client Validation introduced w/ MVC 3, we have to create .NET code for our server-side validation, and jQuery (or JavaScript code) for client-side validation.
I understand that there's no such thing as a .NET-to-jQuery translator that would facilitate DRY server/client validation, and I guess that would be the only way to have true DRY validation that works both server and client side.
But I would be perfectly content with having custom validation always performed on the server. The data needed to pass into custom validation (in my case) is usually limited to one or two fields, and the server-side logic is usually pretty quick, even if it has to hit the database.
Is there no OOTB mechanism for wiring up custom validation using attributes, then having your client side validation use Ajax to execute the validation server-side and respond to the client? Or, has someone come up with such a solution?
Or is it a matter of, in the end, the tradeoffs of repeating the custom validation is better than the issues introduced w/ always executing custom validation server side?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
AFAIK，没有什么 OOTB（开箱即用）。
至于权衡 - 虽然违反了 DRY，但您可以获得以下好处：
当然，除了违反 DRY 并让自己面对这些问题之外，您最终还会为客户端提供更大的有效负载（额外的 JavaScript）。
没有人可以告诉您这些权衡是否值得 - 您需要决定什么最适合您的应用程序、用户和客户。
AFAIK, there is nothing OOTB (Out Of The Box).
As for the tradeoffs - though violating DRY, you gain several things:
Of course, apart from violating DRY and opening yourself to those issue, you also end up with a larger payload to the client (extra javascript).
No one can tell you whether these tradeoffs are worth it - you need to decide what is right for your application, users and client.
OOTB： http:// msdn.microsoft.com/en-us/library/system.web.mvc.remoteattribute(v=vs.98).aspx
您并没有真正在此处验证 DRY。 DRY 的概念比简单的代码复制更加微妙。存在可接受的权衡，特别是在考虑耦合问题时。
当人们问这个问题时（如果你四处搜索的话，这种问题很常见），我通常将他们称为 DDD 概念 有界概念< /a>.在验证时使用 [Remote] 并强制 DRY 往往会将大量关注点聚集在一个地方，并合并多个层的职责。业务逻辑与持久性和数据完整性逻辑（非空）。
@Darin Dmitrov 在他对这个问题所做的很多回答中都说得很好。验证必填字段是否已填写与确保 Sally 拥有足够的信用来进行购买有很大不同，因此应以截然不同的方式对待。
客户端验证最适合用于基本问题，而不是因更繁重的操作而超载。客户端验证对可用性的影响确实很小。发布表单并等待刷新并没有什么“不可用”的地方。它更流畅，但不会影响您应用程序的成功或失败。
OOTB: http://msdn.microsoft.com/en-us/library/system.web.mvc.remoteattribute(v=vs.98).aspx
You aren't really validating DRY here. The concept of DRY is a bit more nuanced than simple duplication of code. There are acceptable tradeoffs, especially when coupling concerns are taken into account.
When people ask this question, which is quite often if you search around, I usually refer them to the DDD concept of bounded concepts. Using
[Remote]and forcing DRY when it comes to validation tends to bunch up tons of concerns in one place and merging the responsibilities of several layers. Business Logic vs. Persistence and Data Integrity Logic ( non nulls ).@Darin Dmitrov says it pretty well in a lot of his answers he's made to this exact question. Validating that a required field is filled in is much different from making sure Sally has enough credit to make a purchase and should be treated much differently.
Client validation is best used for basic concerns and not be overloaded with more heavy operations. The impact on usability from client validation is really minimal. There is nothing "unusable" about posting a form and waiting for a refresh. It is more fluent but not anything that will make or break the success of your application.
在这种情况下，我并不真正同意您对违反 DRY 原则的担忧，但看起来其他几个人已经讨论过这个问题。
但是，您的想法听起来很像 MVC 3 中添加的新远程验证功能：
如何：在 MVC3 中实现远程验证
另一方面，没有什么可以阻止您在客户端执行所有内置的简单检查，并执行所有操作仅在发回服务器时进行大量自定义验证。
I don't really share your concerns about violating the DRY principle in this case, but it looks like a couple other people have already discussed that.
However, your idea sounds a lot like the new remote validation feature that was added with MVC 3:
How To: Implement Remote Validation in MVC3
On the other hand, nothing is stopping you from having all of the built-in simple checks performed on the client side, and doing all of the heavy custom validation only when posting back to the server.