在一个完美的世界中，您可以在商家逻辑层中进行验证（验证）输入，而不是演示文稿或持久层。实际上，你可以（或想要）将它放在任何地方。
让我们使用像JSF或ZK这样的框架制作一个简单的样本（ web-application ）：某个输入字段在0001和0500之间接受4位数字。
您可以使用Web框架的约束功能来执行此操作。方便用户使用，无需额外加载服务器。
您可以在业务层（例如java-ejb）中执行此操作。万无一失，因为使用相同ejb的所有应用程序都将使用相同的验证。最终不好，因为你需要在评估后向用户扔回错误。需要往返服务器往返。
如果某人（通过持久层）输入非数字值或超过4位数的值，您可以（部分）依赖数据库失败。难看。
恢复：您将在1.和2中执行此操作（冗余）。（使用户感觉良好，并使其与所有应用程序保持一致）。 （加上DB col的长度为4）
现在问题：您如何记录此验证？文本文档还是UML图？在某种程度上，您可以在最多3个位置拥有业务逻辑。在复杂系统中，这几乎无法跟踪和理解。
以上示例的真实场景：您需要将4位数更改为5位数。如果没有文档，您需要寻找可能需要更改的位置。
你有什么经历？有什么提示或工具吗？
欢呼声
斯文
答案 0 :(得分：1)
在我的一个项目中，我能够使用正则表达式完成所有验证。幸运的是，我的数据库（PostgreSQL）支持正则表达式约束。通过在数据库模式级别定义正则表达式，我能够轻松地在整个应用程序中使用正则表达式验证。然后由应用程序逻辑继承，然后由客户端javascript验证引擎继承。
因为，我的同事和我都是流利的SQL，它是我们自我记录的。快速检查数据库的表定义将告诉您验证规则。如果我们需要生成正式文档，那么从数据库元数据中提取信息将是微不足道的。
我知道我的经验有点独特，但我想强调正则表达式是一种相对自我记录的便携式解决方案。
答案 1 :(得分：1)
诀窍是坚持DRY（不要重复自己）校长。
实现这一目标有几种不同的方式：
在不同的地方复制约束，然后“记录”它（添加另一个复制！）是效率低下的一个因素！