验证设计和文档答案

【问题标题】：Validation Design and Documentation验证设计和文档
【发布时间】：2009-07-23 07:19:35
【问题描述】：

在理想情况下，您在业务逻辑层而不是在 演示文稿 或 中对输入进行验证（验证） >持久层。实际上，您可以（或希望）将其放置在任何地方。

让我们做一个简单的示例（web-application 使用 JSF 或 ZK 等框架）：某个输入字段接受 0001 和 0500 之间的 4 位数字。

您可以使用 Web 框架的约束功能来执行此操作。方便用户，无需额外的服务器负载。
您可以在业务层（例如 java-ejb）中执行此操作。万无一失，因为所有使用相同 ejb 的应用程序都将使用相同的验证。最终不好，因为您需要在评估后向用户抛出错误。需要往返服务器。
如果有人（通过持久层）输入非数字值或超过 4 位的值，您可以（部分）依赖数据库失败。丑。

简历：您会在 1. 和 2. 中这样做（冗余）（让用户感觉良好，并使其对所有应用程序保持一致）。（加上 DB col 的长度为 4 ）

现在是问题：您如何记录此验证？文本文档还是 UML 图？在某种程度上，您最多可以在 3 个位置拥有业务逻辑。在复杂的系统中，这几乎是不可能跟踪和理解的。

上述示例的真实场景：您需要将 4 位更改为 5 位。如果没有文档，您需要寻找可能需要更改的位置。

你有什么经验？有什么提示或工具吗？

干杯
斯文

【问题讨论】：

【解决方案1】：

在我的一个项目中，我能够使用正则表达式进行所有验证。幸运的是，我的数据库 (PostgreSQL) 支持正则表达式约束。通过在数据库模式级别定义正则表达式，我能够轻松地在整个应用程序中使用正则表达式验证。然后由应用程序逻辑继承，然后由客户端 javascript 验证引擎继承。

因为我和我的同事都精通 SQL，所以它对我们来说是自我记录的。快速检查数据库的表定义会告诉您验证规则。如果我们需要生成正式的文档，将信息从数据库元数据中提取出来是很简单的。

我知道我在这里的经历有点独特，但我想强调正则表达式是一种相对自记录的可移植解决方案。

【讨论】：

【解决方案2】：

诀窍是遵守DRY（不要重复自己）原则。

有几种不同的方法可以实现这一目标：

在不同的地方复制约束，然后“记录”它（添加另一个重复！）是效率低下的秘诀！

【讨论】：