数据验证应该在哪里进行？答案

【问题标题】：Where should data validation occur?数据验证应该在哪里进行？
【发布时间】：2011-01-27 17:25:13
【问题描述】：

我读过关于应该在哪里进行数据验证的相互矛盾的哲学，这让我更加困惑。有人说它应该只在数据库中。其他人说验证规则应该反映在 bll 或 ui 等其他层中。

数据验证应该在哪里进行？规则应该跨多个层拆分吗？关于何时何地验证在数据库之上运行的应用程序中的数据，有哪些实际的最佳实践（与理论相反，头在云中类型的东西）。

【问题讨论】：

它肯定应该在后端 - 如果它可行并且对您的应用程序有帮助，那么也在前端进行验证。但永远不要仅仅依赖前端验证 - 在将任何数据插入数据库之前不要信任任何数据 - 始终在数据库级别验证（引用完整性、CHECK 约束等） - 没有例外。

【解决方案1】：

我的 2 美分：

数据验证应在两个位置进行：

作用于数据的点，例如验证 SQL 查询的输入参数。
在提交数据时进行常规验证，例如在 Web 应用程序中，一些验证应在客户端进行。优点是您可以快速通知用户输入问题，即电话号码格式不正确、字符串太长等。但是，这不应被视为权威验证检查，因为在 Web 应用程序的情况下，恶意用户可能会绕过客户端验证。

在我看来，数据库不应该执行一般验证，数据应该在进入数据库之前进行验证/转义/清理。也就是说，您的数据库架构可以通过列数据类型、约束等为您提供一定程度的抽象验证。也就是说，任何可能触发这些问题的数据都应该在传递到数据库之前“清理”。

这就是说，有很多错误的方法，但没有正确的方法。验证取决于应用程序的架构、其中数据的性质以及数据的使用方式。

【讨论】：

那么您将永远不会执行引发错误的数据库查询（除了非应用程序错误，如连接问题）。本质上，您的应用程序会执行所有需要进行的验证。听起来对吗？
您永远无法绝对确定您的数据库查询不会因数据错误而引发错误，因此您的应用程序应该处理它。但是，您可以做很多事情来防止这种事情发生。通常，数据库可以进行基本验证（约束、数据类型等），但处理除此之外的任何事情同时能够优雅地处理验证失败会更加复杂。此外，为什么要使用包含未验证数据的查询来加载数据库，您的应用程序可以处理它，并且扩展应用程序比扩展数据库要容易得多。

【解决方案2】：

应该这样做：

因此，例如，在数据库驱动的 Web 表单应用程序中，您将进行客户端 JavaScript 验证，可能在业务逻辑中进行一些服务器端验证，然后在数据库中进行进一步的约束，范围从数据类型到检查约束。

【讨论】：

你复制每一层的所有规则吗？如果没有，你如何决定哪些规则进入哪一层？
如果您遵循上述指南，这意味着您必须为每一层添加验证，然后为每一层添加验证。这是基于优点，而不是某些可能不适合您的应用的规则。
+1 将商业逻辑描述为横切关注点。
@Jeff，我想我误解了你的问题。您不必完全复制每一层中的所有规则，只需确保每一层都验证到所需的点即可。例如，数据库中的数据类型显式设置了一种验证类型（例如 int 或 string），但由于其性质，这可能只是在另一层中隐含（它是否表示为 int 9 或 string "9 可能无关紧要”别处）。