三层架构中的验证

Question

假设有一个 Employee 类，业务需求之一是 EmployeeName 变得唯一。现在使用 3 层架构，

第 1 层：表示
层 第 2 层：域模型 + 数据服务类（业务逻辑层）
第 3 层：数据访问类 + 存储过程（数据访问层）

既然上面的需求是业务需求，您认为这条规则最好放在哪里？

选项 1：数据库中的唯一键约束

选项 2：检查业务层数据服务类中的条件，以便无论使用哪个数据层，都将业务逻辑封装在该层中？

Answer 1

在所有三层中。然而，重要的是验证要求（=实际数据约束）因层而异的常见事实。这是因为不同的环境和设计的系统边界。

\n\n

在您的示例中，验证可能如下：

\n\n

\n
• 第 1 层：表示层 \xe2\x80\x94 验证名称是否已输入，即用户界面中的文本框不为空，并且最多有 100 个字符。
\n
• 第 2 层：业务逻辑层 - 如上所述进行验证，加上它由至少两个由空格分隔的标记组成，加上名字和姓氏是真实的名字和姓氏（对照某些名称数据库进行检查）。
\n
• 第 3 层：数据层 - 数据库完整性约束，相应字段不为空且最大长度为 100 个字符。
\n

\n\n

结果是，从数据库的角度来看，您检查合理数量的约束以保持系统的一致性，但不要假设存在高阶逻辑问题。事实上，您不会不必要地限制未来的更改。从业务逻辑的角度来看，强制执行了完整的约束集。最后，从表示逻辑的角度来看，您不会过度验证：仅执行简单的验证以减少不必要的业务逻辑流量，可能会防止业务逻辑层出现异常，而不是重复任何更复杂的事情。

\n\n

根据经验，在业务逻辑层的外观提供详细的验证始终是最佳实践。这是（可能不受信任的）表示层和/或第 3 方（可能只是另一个公司系统）API 消费者连接的地方。

\n\n

此外，对您在问题中概述的选项的一些具体评论：

\n\n

\n

选项 1：数据库中的唯一键约束

\n

\n\n

不仅。从数据正确性的角度来看，它是可行的，但仅依赖数据库约束，您就会失去语义，并且很难提供人类可理解的错误消息。此外，每个错误的输入都会传输到数据库，从而为 DoS 攻击打开一个潜在的漏洞，从而可能损害整个技术堆栈。

\n\n

\n

选项 2：检查业务层数据服务类中的条件，以便无论使用哪个数据层，都将业务逻辑封装在该层中？

\n

\n\n

是的，见上文。但是，不要通过避免至少在表示层中进行基本的、易于评估的验证来损害安全性、性能和用户体验。

\n