2

我想弄清楚如何在业务对象上使用验证。

到目前为止，我只在CustomValidator上看到过仅检查 1 个错误的示例。我有两个带有 DateTime 输入的字段，应该检查 3 个或更多错误。我想通常我应该检查客户端，然后检查服务器，最后检查数据库级别。

  • 如果我在某个字段上遇到错误，我应该无法离开该字段。
  • 在客户端验证上，这不是应该导致异常的错误，因为它只是一个用户错误。但是如果出现问题并且用户绕过了客户端验证，服务器验证应该抛出一个异常。
  • 最后，如果我有其他例如批量更新工作，那么他们应该使用数据库验证代码。如果我错过了一些基本的东西，请纠正我！
  1. `dateFrom` 不为空。（但 `dateTo` 可以为空）
  2. `dateFrom` 早于 `dateTo`
  3. `dateFrom` 和 `dateTo` 在常量 `MinDate` 和 `MaxDate` 内

那么我的验证应该是什么样子，客户端、服务器和数据库？

想法：

验证逻辑是否应该在 3 个不同的地方分开；UI、代码和数据对象（数据库）？什么时候是完全相同的代码？似乎多余？

我可以对所有三项检查使用相同的验证方法吗？还是我需要实现 3 个代码块和每个 3 个方法，然后如何在 ValidationSummary 中很好地列出所有内容？

4

2 回答 2

2

为了减少代码重复和由此产生的错误，所有验证代码都应该在一个单一的层 - 最好是业务层，因为它处于评估对象并确定它是否有效的最佳位置。

然而，虽然这是一个理论上的理想，但在现实世界的情况下通常并不实用。在客户端-服务器环境中，如 ASP.NET，您希望在客户端尽可能多地复制验证，以减少到服务器的往返行程。此外，如果您有其他业务过程（例如批量上传）在不通过业务对象的情况下接触您的表，您还需要在数据库中实现验证，以防止创建垃圾数据。

对于您的示例中的验证，我将在我的业务对象和三个 CustomValidators 上创建三个验证方法 - 每个验证器将在服务器端的业务对象上调用相应的方法。我还会编写一些 JavaScript 代码以在客户端运行，因此服务器端代码将仅用于捕获未启用 JavaScript 的浏览器或恶意制作的 HTTP 请求。

对于在 JavaScript 中难以进行的验证（即需要业务对象），我不会使用 CustomValidator。相反，这些验证等到用户按下提交按钮，此时我可以使用业务对象来验证自身并返回任何错误。

于 2010-02-22T14:22:36.157 回答
1

通常，通常情况下，业务层中的验证是好的；JS 验证也很好，因为它有助于减少往返。对于 CustomValidator，有一个 cleintvalidationfunction 属性，它采用在客户端上验证的方法的名称，将其设置为方法的名称以进行验证（请查看 MSDN 文档，抱歉，手边没有链接，但 MSDN 有一个明确的例子）。

此外，对于服务器，servervalidate 事件也可以触发以从代码验证表单，您也可以在此处进行数据库检查。

不确定您在 DataObject(Database) 中做了哪些检查？

于 2010-02-22T14:03:38.740 回答