外观和 DAO 之间适合什么模式？答案

【问题标题】：What pattern fits between a façade and a DAO?外观和 DAO 之间适合什么模式？
【发布时间】：2023-04-05 03:49:01
【问题描述】：

我正在为其 Java EE Web 应用程序设计公司架构的一部分。我很清楚使用外观和一个或多个 DAO 的原因。我遇到的问题是这样的：

肯定会有一些逻辑属于集成层，因为这完全是为了保持数据模型的一致性。除了逻辑超出了简单地维护引用完整性和其他将由 JPA 和 Hibernate 处理的“原始”持久性任务之外。我不将其归类为业务逻辑，因为它与任何业务功能分开。但是，我的理解是，DAO 应该只实现访问对象并将对象持久保存到数据源所需的逻辑。

我的结论是，我需要一个适合集成层的类似“业务对象”的模式。我环顾四周，发现最接近的东西（但在我看来仍然不太正确）是Sun Transfer Object Assembler pattern。

要么我对 Java EE 的理解存在差距，要么存在适合的模式。

【问题讨论】：

标签： java design-patterns jakarta-ee

【解决方案1】：

也许mediator 是你想要的：

定义一个对象，该对象封装一组对象如何交互。 Mediator 通过阻止对象显式地相互引用来促进松散耦合，并且它允许您独立地改变它们的交互。

那么您可以使用DaoMediator 来协调两个或多个DAOs

【讨论】：

阅读所有答案后，我的感觉是调解员是我们的出路。非常感谢您的回复。他们都提供了非常丰富的信息。

【解决方案2】：

在我看来，您可能缺少控制器，因此可能需要MVC 模式。控制器将负责 DAO 并呈现一致的视图（不要考虑 GUI，而是一些面向客户端的界面）。当通过此视图进行修改时，控制器会通过 DAO 协调对模型的更改。我怀疑您的外观对象可能是这种情况下的视图。

话虽如此，我不会担心太多关于识别特定模式的问题。您经常会发现，考虑到您的所有需求并在适用的情况下分离关注点，您最终会实现特定的模式，并且只是在事后才将其识别出来。

【讨论】：

【解决方案3】：

您是否考虑过使用领域驱动设计中的聚合？我自己是 DDD 的学生，您尝试设计的业务逻辑似乎可以通过更丰富的类似 POJO 的域模型来完成。你会拥有每一个域对象负责其聚合对象，还包括与该业务概念有关的任何逻辑；也就是说，您的集成层将协调这些丰富的对象，但会避免拥有真正的逻辑本身（即几个条件逻辑）。

也许您试图找到的模式实际上是向更丰富的领域对象迈出的一步？

【讨论】：

【解决方案4】：

我认为这是 DAL 和业务层之间的 DataMapper（或适配器）模式，但如果没有更具体的理解，我无法确定。

【讨论】：

【解决方案5】：

是什么推动了 DAO 之间的一致性要求？如果有一些商业假设决定了这种关系。例如，您可能有一个发票类型，当它是“资本”时，我们必须确保其他几个对象处于正确的状态或具有正确的值集。这绝对超出了数据层的范围。

我不会努力为这种情况找到完美的模式。不过，您需要某种协调类，某种中介者或控制器。

【讨论】：