验证设计和文档

Question

在一个完美的世界里，你必须投入在业务逻辑层的验证（验证），而不是在呈现或持久层。实际上你可以（或者想）把它放在任何地方。

允许作简单的样品（使用像JSF或ZK框架web的应用）：一定输入字段接受0001和0500之间4位

1. 你可以使用的约束特征你的web框架来做到这一点。方便用户，不需要额外的服务器负载。

2. 你可以在业务层（例如java-ejb）做到这一点。万无一失，因为所有使用相同ejb的应用程序都将使用相同的验证。最终不好，因为你需要在评估后向用户抛出错误。需要往返于服务器。

3. 如果有人输入（通过持久层）非数字值或超过4位数的值，您可以依靠（部分）数据库失败。丑陋。

简历：您可以在1.和2.中做到这一点（多余）。（让用户感觉很好，并使所有应用程序保持一致）。 （加上DB col的长度将是4）

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

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

你会遇到什么？任何提示或工具呢？

欢呼
斯文

Answer 1

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

因为，我的同事和我都是SQL流利的人，所以这是自我记录给我们的。快速检查数据库的表格定义会告诉你验证规则。如果我们需要生成正式的文档，那么将信息从数据库元数据中提取出来将是微不足道的。

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

Answer 2

诀窍是坚持DRY（不要重复自己）校长。

有实现这个目标的几种不同的方式：

1. 在传播到 业务和UI层
2. 定义业务层（Java）的约束DB（以利亚的 法）规定的约束和使用GWT运行相同的代码使用GWT
3. 等等，我相信有很多其他方法可以实现相同的结果。

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