门面/服务架构

Question

在我提出问题之前，我必须描述我们的应用程序是如何构建的。

我们运行了几个在服务层使用ejb的Web应用程序。我试着用一个简短的例子来描述沟通：

• JSF bean（PersonH​​andler）调用facade来删除“Person”对象
• Facade可以使用许多不同的服务，但不能使用其他外墙。在这种情况下，PersonFacade使用PersonService（删除人员）和NotificationService（发送电子邮件）。事务也由外观逻辑控制。只有在成功提交交易时才能发送电子邮件。
• 服务无法引用其他服务或外观。而不是这个，PersonService只引用了PersonDao（持久逻辑）。

我认为这种架构很常见。这是我的问题。

在PersonFacade的删除方法中，我们有非常重要的代码，我们不会复制。每次删除一个人时，这段代码都应该运行。在另一个外观逻辑中，我们需要完全相同的代码，但外观＆lt; - ＆gt;不允许门面沟通。

这个问题的最佳解决方案是什么？

这是我当前的解决方案，但我对它不满意。我创建了一个新的ejb模块，其中包含一个处理删除逻辑的ejb。两个外观模块都依赖于新模块，所以一切都可以找到，我不打破“外墙从不使用其他外墙”合同。如果我们每次都使用这个，我们需要在不同的地方使用相同的代码，我们的模块会爆炸，模块会变得混乱。目前我们有超过250个ejb / jar模块。

Answer 1

以下是我会考虑的两个选项。

1. 在所有立面将延伸的基础外观中具有通用逻辑，或
2. 将公共逻辑移动到任何Facade可以调用的辅助类（实用程序）。我看到你已经通过创建一个新的ejb做了类似的事情。我不确定它是否需要成为一个ejb，取决于确切的逻辑。