三层架构中业务逻辑层内的交互？ [关闭]答案

【问题标题】：Interaction within Business Logic Layer in 3-layered Architecture? [closed]三层架构中业务逻辑层内的交互？ [关闭]
【发布时间】：2021-10-18 09:44:38
【问题描述】：

我们遵循 3 层架构，其中我们有表示层、业务逻辑层（管理器）和数据访问层。很少有进程涉及由不同 BLL 类控制的多个实体（我们将 BLL 类称为管理器）。我们可以让一个 Manager 类与另一个 Manager 类水平交互吗？想知道社区的意见，因为仅仅依赖 Manager-DAL 流程会造成很多代码重复。

【问题讨论】：

标签： oop design-patterns n-tier-architecture 3-tier business-layer

【解决方案1】：

我看不出有什么特别的问题，而且这种情况发生的频率也比你想象的要多。例如，在分层客户端应用程序中，在数据层中，您通常会找到一个与框架/平台特定缓存（通常写入 HD）对话的类。由于框架和数据层处于相同的低抽象级别，因此它们可以在没有架构中断的情况下进行通信。

应该避免的主要是从更抽象的层（实体/域/业务层）到不太抽象的层（数据或表示层）的依赖方向。

【讨论】：

我还要补充一点，交叉交互对于同一级别的演员来说可能是一件坏事，例如，经理 A 呼叫经理 B，而经理 B 又呼叫经理 A。因为它更难记住控制流，有时会导致错误和数据竞争。
域到域对象的交互完成没问题。但是，如果您只有“Manager”类或 Handler 类，那么这意味着您实际上并没有域模型
您可能有一个事务脚本的变体，其中经理按程序执行。现在你发现管理者之间有一些重用。只要确保经理之间的互动是有意义的。也许将 Manager 分成几个不同的域对象将是一个好主意 - 并且只使用 Manager 来公开这些对象组的功能。管理器类应该很薄。如果它们处理多个职责，那应该为您提供重构设计的起点。
另外我想补充一下，两个互动的Manager是什么关系？它是业务领域中的交互吗？例如，灯泡连接到电路域中的开关。因此，我的灯泡实体应该通过电路连接器实体与我的 SwitchEntity 建立关系但是如果我的 SwitchManager 类仅仅因为 SwitchBulbClass 中的某处而依赖于 LightBulb 类，那么有一行代码调用了 LightBulb 类，这是一个错误的抽象。它不能很好地扩展，并且还会将问题传播到其他层。