在3层架构中验证

Question

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

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

由于上述要求是业务要求，您认为放置此规则的最佳位置在哪里？

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

选项2：检查业务层中数据服务类中的条件，以便将业务逻辑封装在此层中，而不管所使用的数据层是什么？

Answer 1

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

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

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

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

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

此外，您对问题中列出的选项提出了一些具体意见：

  

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

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

  

选项2：检查业务层中数据服务类中的条件，以便将业务逻辑封装在此层中，而不管所使用的数据层是什么？

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