【问题标题】:Validation in a WebForms applicationWebForms 应用程序中的验证
【发布时间】:2012-12-21 15:39:45
【问题描述】:

我正在开发一个由多个页面组成的 WebForms 应用程序,每个页面都包含一个用户填写的表单。每个表单对应于实体的一部分,这意味着来自一个页面/表单的数据填充实体字段或其子实体字段的一部分。

例如:第一页填写个人姓名和出生数据,第二页填写健康状况,第三页填写家庭信息等。 在继续下一页之前,数据当然应该是有效的。我的客户不想处理 jQuery 或 Javascript,所以这被排除在外。在这种情况下实施验证的“最佳实践”是什么?

正在使用 Entity Framework 4,大多数 GUI 控件都是用 HTML 实现的,而不是通过 WebForms 控件实现的。

【问题讨论】:

  • 好吧,RequiredFieldValidatorRegularExpressionValidator 呢?
  • 但是这些是 WebControls,不能用于 html-elements 对吧?
  • 你说得对,我看错了。
  • “我的客户不想处理 jQuery”。希望没有用户必须编写 javascript。我们开发人员将为他们做这件事。不允许任何干净的验证是邪恶的。为什么他们有这个要求?
  • 客户端验证很好,让 UI 响应更快,用户更有效率。但是,您也应该始终在服务器上进行验证。不这样做将是一个安全错误。这就是 ASP.NET 验证控件为您执行客户端和服务器验证的原因。

标签: asp.net validation webforms


【解决方案1】:

如果您使用自定义 HTML 进行输入,那么您可能必须使用一些自定义代码进行验证。在您的服务器端表单处理程序中,您可以验证输入并在某些内容无效时将页面呈现给用户。输入检查可以很简单:

if (string.IsNullOrWhiteSpace(FormCollection["someRequiredInput"])

您可以遍历所有输入,根据业务逻辑检查它们,或许还可以构建一个错误列表。然后在输入检查之后,如果错误列表不为空,则将页面呈现给用户,并将错误添加到某种占位符中。如果列表为空,则继续处理表单发布。

即使不排除 JavaScript,您仍然希望执行服务器端验证。 从不假设客户端代码按预期工作,甚至完全执行。客户端验证不是一种安全措施,它只是一种更好的用户体验。服务器端验证是唯一真正的验证。

(因此,您仍然可以为添加的 UX 触摸添加客户端验证,如果客户端确实不允许 JavaScript,那么他们将看不到这一点,而只会使用服务器端验证。这是有时被称为“优雅降级”,当用户禁用客户端技术时,您设计的 Web 应用程序仍可完全运行,尽管 UX 性能稍差。)

【讨论】:

    【解决方案2】:

    我的客户不想处理 jQuery och[sic] Javascript,所以这被排除了。

    很好。 Javascript 是强制验证的错误地方。您使用 javascript 进行的任何验证都只是性能优化。 唯一可以接受真正验证数据的地方是在服务器上。

    顺便说一句,.Net 包含一些您可以使用的方便的验证控件。其中一个控件是 CustomValidator,它很容易覆盖并提供您自己的服务器端代码来执行您想要的任何规则。如果您使用网络表单,这些控件是显而易见的选择。

    由于您使用的是多页方法,您可能还需要查看 Wizard 控件。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2015-12-24
      • 1970-01-01
      • 1970-01-01
      • 2011-04-03
      相关资源
      最近更新 更多