我在ASP.NET Web窗体环境中使用ASP.NET验证控件。更好的方法是保持服务器端的所有验证规则，比如使用AJAX来验证字段，而不需要发布整个页面。ASP.NET AJAX验证控件
我发现一个名为ValidatorCallout的控件（http://www.asp.net/ajax/ajaxcontroltoolkit/samples/ValidatorCallout/ValidatorCallout.aspx），但试图找出是否有更好的方法。
无论您是否进行任何客户端验证，您都应该始终执行服务器端验证。这是因为围绕客户端验证有很多方法，例如关闭js或发送不使用页面的自定义构建请求。
在客户端和服务器上使用相同的验证规则是一个不错的目标。 xVal是一个很好的选择。
这方面的一个很好的例子就是我如何因为我们去迪拜的行程而入侵某个航空公司的网站。当我为我的女儿（两岁以下）选择一顿特殊餐时，选择列表中没有“孩子”选项。显然，儿童餐仅适用于年龄大于2岁的儿童。我的大女儿有一个孩子的选择。所以我打开了Firebug，添加了选项，选择了它并提交了表单。它被接受了。
在飞行中，两个孩子的饭菜按照指令打开了。
该死！想想看，我应该把它改成头等舱！戴森先生，不在球上！
感谢您查看这个较旧的问题。基本上我想摆脱整个页面客户机的偏差，因为验证控件创建了大量的JavaScript调用。我正在寻找一种解决方案，我可以在业务对象中使用我的验证规则，但是使用AJAX通过部分页面回发来模拟客户端验证。服务器端验证将始终存在。 – Josh 2010-09-28 16:33:58
没问题。使用AJAX调用服务器端验证代码是一个很好的折衷方案。关于xVal的好处是您可以在多个客户端和服务器端实现之间进行选择。 xVal执行翻译。我个人更喜欢在服务器上的客户端和FluentValidation上使用jQuery Validation。基于FluentValidation规则，xVal发出jQuery验证规则。 – 2010-09-28 16:39:26
我目前使用的是Web Forms，而不是MVC，但是对于我的下一个项目，我会使用MVC并进行一下。它看起来不像xVal已经在一年中更新。它还是一个活跃的项目吗？ – Josh 2010-09-29 14:50:17
我也使用了ValidatorCallout，并且很惊喜。你的具体问题或你的担忧是什么？ – 2010-05-26 18:36:59
顺便说一句：我不明白你的问题关于服务器端验证。最好做客户端和服务器端验证。这两个ValidatorCallout都没有问题。 – 2010-05-26 18:42:40
理想情况下，我将所有验证逻辑服务器端与业务对象关联起来，而不是在客户端的每个字段中创建相同的规则。所以表单会通过AJAX调用客户端来验证部分页面回发的字段。坦率地说，我想要更干净的HTML，所以我没有嵌入HTML中的大量验证控件。 – Josh 2010-05-26 18:46:53