假设有一个 Employee 类，业务需求之一是 EmployeeName 变得唯一。现在使用 3 层架构，
第 1 层：演示
第 2 层：领域模型 + 数据服务类（业务逻辑层）
第 3 层：数据访问类 + 存储过程（数据访问层）
既然上面的需求是业务需求，那么你认为把这条规则放在哪里最好？
选项1：数据库中的唯一键约束
选项2：在业务层的Data Service类中检查条件，以保持业务逻辑封装在该层中而不管正在使用的数据层吗？
【问题讨论】：
标签： validation 3-tier
在所有三层中。然而，重要的是验证要求（=实际数据约束）因层而异。这是因为不同的上下文和设计的系统边界。
在您的示例中，验证可能如下：
结果是，从数据库的角度来看，您检查合理数量的约束以保持系统一致，但不要假设高阶逻辑是什么问题。事实上，您不会不必要地限制未来的变化。从业务逻辑的角度来看，有一套完整的约束被强制执行。最后，从表示逻辑的角度来看，您不要过度验证：只执行简单的验证以减少对业务逻辑的不必要流量，可能防止业务逻辑层出现异常，而不是重复任何内容更复杂。
根据经验，始终最佳实践是在业务逻辑层的外观提供详细的验证。这是（可能不受信任的）表示层和/或第 3 方（可能只是另一个公司系统）API 消费者连接的地方。
此外，您在问题中概述的选项的一些特定 cmets：
选项1：数据库中的唯一键约束
不仅如此。从数据正确性的角度来看，它会起作用，但仅依靠数据库约束，您将失去语义，并且难以提供人类可以理解的错误消息。此外，每一个错误的输入都会传递到数据库，从而为 DoS 攻击打开一个潜在的漏洞，这可能会损害整个技术堆栈。
选项2：在业务层的Data Service类中检查条件，以保持业务逻辑封装在该层中而不管正在使用的数据层吗？
是的，见上文。但是，不要通过至少避免表示层中基本的、易于评估的验证来损害安全性、性能和用户体验。
【讨论】：