java - 验证设计和文档

Question

在完美的世界中，您可以在业务逻辑层中对输入进行验证(验证)，而不是在表示或中>持久层。实际上，您可以(或想要)将其放置在任何地方。

让我们制作一个简单的示例(网络应用程序，使用 JSF 或 ZK 等框架):某个输入字段接受 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，因此它对我们来说是 self 记录的。快速检查数据库的表定义将告诉您验证规则。如果我们需要生成正式文档，从数据库元数据中提取信息将是微不足道的。

我知道我在这里的经历有点独特，但我想强调正则表达式如何成为一种相对自文档化的可移植解决方案。