验证设计和文档
在完美的世界中，您可以在业务逻辑层而不是表示或持久层中对输入进行验证（验证） 。 实际上，您可以（或想要）将其放置在任何地方。
让我们做一个简单的示例（网络应用程序使用 JSF 或 ZK 等框架）：某个输入字段接受 0001 到 0500 之间的 4 位数字。
您可以使用 Web 框架的约束功能去做这个。 方便用户，无需额外的服务器负载。
您可以在业务层（例如java-ejb）中执行此操作。 万无一失，因为使用相同 ejb 的所有应用程序都将使用相同的验证。 最终不好，因为您需要在评估后向用户返回错误。 需要往返服务器。
如果有人（通过持久层）输入非数字值或超过 4 位数字的值，您可能（部分）依赖数据库失败。 丑陋。
恢复：您将在 1. 和 2. 中执行此操作（冗余）（使其对用户有利并使其对所有应用程序保持一致）。 （加上 DB col 的长度将为 4）
现在问题：您如何记录此验证？ 文本文档还是 UML 图？ 在某种程度上，您最多可以在 3 个位置拥有业务逻辑。 在复杂的系统中，这几乎不可能跟踪和理解。
上述示例的现实生活场景：您需要将 4 位数字更改为 5 位数字。 如果没有文档，您需要寻找可能需要更改的位置。
你有什么经历？ 有什么技巧或工具吗？
干杯
斯文
In a perfect world you have the validation (verification) of inputs in the business logic layer, not in the presentation or persistence layer. In reality you can (or want) to place it anywhere.
Lets make a simple sample (web-application using a framework like JSF or ZK): A certain input field accepts 4 digits between 0001 and 0500.
You could use the constraint features of your web framework to do this. Convenient for user, no additional server load.
You could do it in business layer (eg java-ejb). Foolproof because all applications using the same ejb will use the same validation. Eventually not nice because you need to throw back error at user after evaluation. Needs roundtrip to and from server.
You could rely (partially) on the DB to fail if someone enter (via persistence layer) a non-digit value or a value with more than 4 digits. Ugly.
Resume: You would do it (redundant) in 1. and 2. (Make it nice for the user and make it consistent for all applications). (Plus the length of DB col would be 4 )
Now the QUESTION: How you document this validation ? Text document or an UML diagram ? In a way you have business logic in up to 3 locations. In complex systems this close to impossible to track and understand.
Real life scenario for above sample: You need to change from 4 to 5 digits. Without documentation you need to hunt for the locations where changes might be required.
Whats you experience ? Any tips or tools for this ?
cheers
Sven
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在我的一个项目中，我能够使用正则表达式完成所有验证。 幸运的是，我的数据库（PostgreSQL）支持正则表达式约束。 通过在数据库架构级别定义正则表达式，我能够轻松地在整个应用程序中使用正则表达式验证。 然后，它被应用程序逻辑继承，然后被客户端 JavaScript 验证引擎继承。
因为我和我的同事都精通 SQL，所以它对我们来说是自我记录的。 快速检查数据库的表定义将告诉您验证规则。 如果我们需要生成正式文档，那么从数据库元数据中提取信息将是微不足道的。
我知道我在这里的经历有点独特，但我想强调正则表达式如何成为一种相对自记录的可移植解决方案。
In one of my projects, I was able to do all of my validation using regular expressions. Luckily, my database (PostgreSQL) supported regular expression constraints. I was able to use regex validation across the entire application with ease by having the regex defined at the database schema level. This was then inherited by the application logic and then by the client-side javascript validation engine.
Since, my coworkers and I were all SQL fluent, it was self-documenting to us. A quick check of the database's table definition would tell you the validation rules. If we needed formal documentation generated, it would be trivial to pull the information out of the database metadata.
I know my experience here is a bit unique, but I want to highlight how regular expressions are a portable solution that is relatively self-documenting.
诀窍是遵守DRY（不要重复自己）原则。
有几种不同的方法可以实现这一目标：
方法）被传播到
业务层和 UI 层
在不同的地方复制约束，然后“记录”它（添加另一个重复！）会导致效率低下！
The trick is to adhere to the DRY (don't repeat yourself) principal.
There are several different ways of reaching this goal:
method) that are propagated to
business and UI layers
Duplicating the constraint in different places, and then "documenting" it (adding another duplication!) is a recipe for inefficiency!