6

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

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

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

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

4

5 回答 5

4

也许调解员是您想要的:

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

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

于 2009-12-02T13:00:10.450 回答
2

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

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

于 2009-12-02T12:35:42.433 回答
1

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

也许您试图找到的模式实际上是进入更丰富的域对象的一步?

于 2009-12-02T14:09:58.767 回答
0

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

于 2009-12-02T12:36:30.077 回答
0

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

我不会努力为这种情况找到完美的模式。但是,您需要某种协调类,某种调解器或控制器。

于 2009-12-02T16:54:21.493 回答