外观/服务架构

Question

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

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

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

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

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

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

这是我目前的解决方案，但我对此并不满意。我创建了一个带有处理删除逻辑的 ejb 的新 ejb 模块。两个外观模块都依赖于新模块，因此一切正常，我不会违反“外观从不使用其他外观”的合同。如果我们每次在不同的地方需要相同的代码时都使用它，我们的模块将会爆炸并且模块会变得混乱。目前我们有超过 250 个 ejb/jar 模块。

Answer 1

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

1. 在基础外观中具有通用逻辑，所有外观都将从该基础外观扩展，或者
2. 将通用逻辑移至任何外观都可以调用的辅助类（实用程序）。我看到您已经通过创建一个新的 ejb 来做类似的事情。我不确定它是否需要是 ejb，这取决于确切的逻辑。