外观和DAO之间有什么样的图案？

Question

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

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

我的结论是，我需要一个适合集成层的'业务对象'模式。我环顾四周，我发现的最接近的事情（但仍然不太适合我的想法）是Sun Transfer Object Assembler pattern。

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

Answer 1

也许mediator就是你想要的：

  

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

然后您可以使用DaoMediator来协调两个或更多DAO个

Answer 2

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

说完这些之后，我不会太担心太多关于识别特定模式的问题。您经常会发现，考虑到您的所有要求并在适用的情况下将问题分开，您最终会实施特定模式，并且事后才会将其识别出来。

Answer 3

您是否考虑过使用域驱动设计的聚合？ 我自己是DDD的学生，看起来你试图设计的业务逻辑可以通过更富有POJO的域模型来实现。你们每个人都有 域对象负责其聚合对象，还包括与该业务概念有关的任何逻辑;也就是说，你的集成层会协调那些丰富的对象，但是会避免使用真正的逻辑本身（即几个条件逻辑）。

您尝试查找的模式实际上是向更丰富的域对象迈出的一步？

Answer 4

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

Answer 5

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

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