三层架构中的验证

Question

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

第 1 层:演示文稿
第 2 层:领域模型 + 数据服务类(业务逻辑层)
第 3 层:数据访问类 + 存储过程(数据访问层)

既然上面的需求是业务需求，那么你觉得把这条规则放在哪里最好呢？

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

选项2:在业务层的Data Service类中检查条件，以保持业务逻辑封装在该层，而不管使用的数据层？

Answer 1

在所有三层。然而，重要的是验证要求(=实际数据约束)因层而异的常见事实。这是因为不同的上下文和设计的系统边界。

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

第 1 层:表示层 — 验证名称是否已输入，即用户界面中的文本框不为空，且最多 100 个字符。

第 2 层:业务逻辑层 - 如上所述验证，加上它由至少两个由空格分隔的 token 组成，加上名字和姓氏是真实的名字和姓氏(对照某些名称数据库)。

第 3 层:数据层 - 数据库完整性约束，即各个字段不为空且最大长度为 100 个字符。

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

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

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

Option 1 : Unique key constraint in the database

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

Option 2 : Checking condition in the Data Service class in the business layer in order to keep the business logic encapsulated in this layer regardless of the data layer being used?

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