java - 使用 EJB 接口(interface)作为辅助类

Question

我的同事告诉我，EJB 本身不应该包含任何方法实现，它只能将方法调用委托(delegate)给一些“帮助器”类，即 EJB 方法应该如下所示:

public String bsuinessMethod1() {
   return helper.bsuinessMethod1()
}

public void bsuinessMethod2() {
   helper.bsuinessMethod2()
}

像上面这样委托(delegate)方法的原因是减少耦合代码(例如，当我想重用不在 EJB 上下文中的“helper”类的方法时)。他还表示，业务方法不应该了解任何有关 Java EE 的信息。

(如果上面的说法有误，请纠正我，请注意我们不使用JPA事务，我们使用另一个框架来处理数据持久化)

因此，如果上述陈述正确，我的“帮助程序”类应该具有与 EJB 相同的方法。那么我可以为辅助类重用 EJB 接口(interface)吗(即让辅助类实现与 EJB 相同的接口(interface))？从架构的角度来看这不是很糟糕吗？

Answer 1

我不认为

delegate method calls to some "helper" classes

，意味着将 ejb 方法保留在一个仅调用帮助器类的行中。将实现委托(delegate)给帮助程序类的目的是通过不同类型的服务公开程序(ejb、pojo、Web 服务等)使用核心计算。这也有助于轻松地将服务从 ejb 移植到非 ejb。

如果需要，在辅助类中进行计算将有助于以多种方式公开服务。他们都可以使用这些辅助类来进行核心计算。

比如说，我们需要一项服务来检索给定城市一天的平均气温。如果这个例子看起来不太好，请原谅，但我希望它表达了这个想法。该服务需要

1. 从数据库中检索给定城市的温度列表那天。 (在 DB 中，它们存储为 40 F、5 C 等)。
2. 解析温度以识别测量单位并转换为华氏度。
3. 过滤无效温度(零和包含无效字符的值等)。
4. 计算平均值。

在这种情况下，将第 2、3 和 4 项移至辅助类是有意义的。不建议将第 1 项作为辅助类的一部分。

现在这个辅助类可以被使用a) pojo 服务。 b) 一个 ejb。 c) 网络服务或其他。