验证ASP.Net用户控件的最佳实践是什么?

时间:2009-03-27 01:02:00

标签: asp.net web-services validation

我想知道是否存在关于应该和不应该进入验证器控件的指南的最佳实践。我的想法和实践是它应该是基本的健全性检查(即用户是否输入了所有必需的输入?电话号码中是否有10位数字,是有效表格中的电子邮件地址等等),但我是最近运行了一些asp.net代码,它使用验证器进行更复杂的验证(即用于验证地址或用户ID和名称匹配的Web服务调用)。

关于如何封装这些更复杂的任务,是否存在任何思想流派?我最初的直觉是验证器是错误的工具,但我真的很想知道其他人的想法或写过的内容。谢谢!

2 个答案:

答案 0 :(得分:0)

你是对的。 p& p团队在企业库中有一个很棒的块,名为验证应用程序块(VAB)。

  

如果您直接从用户收集值,则UI中的验证很好,但您可能需要执行更多操作。例如,您可能需要验证以下对象实例:

  • 在应用程序的单独层或组件中生成
  • 从缓存,存储库或第三方数据访问层检索
  • 从Web服务接收为对象实例或一组属性值
  • 从现有值重建,可能通过从类似对象复制属性或使用从数据库中检索的值来填充它们

我是企业图书馆的忠实粉丝,并且对VAB有很好的体验。如果你不熟悉EntLib,它可能很难第一次 - 但它之后就会变得很糟糕!

VAB为您提供了在一个地方创建,运行和托管规则的选项,但可以在您需要的地方拨打电话。

使用ASP.NET和VAB

15秒:

http://www.15seconds.com/Issue/070607.htm

Tom Hollander关于VAB的博客

<强> http://blogs.msdn.com/tomholl/archive/2006/11/27/validation-application-block-revealed.aspx

答案 1 :(得分:0)

我不知道这是不是最佳做法,但我个人认为,在客户端唯一应该验证的是可以在客户端完全验证的事情。换句话说,如果您必须调用服务器才能执行验证,那么您已经在客户端验证时失去了任何性能提升。 (这就是验证在客户端上的原因 - 通过避免访问服务器来获得性能。)

由于您的业务对象(或应该)在提交上执行相同的验证,因此从编码和维护的角度来看,更有意义的是允许表单在此时提交并执行所有验证。