0

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

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

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

像上面这样委托方法的原因是减少耦合代码（例如，当我想重用不在 EJB 上下文中的“帮助器”类的方法时）。他还告诉业务方法不应该对 Java EE 有任何了解。

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

所以如果上面的陈述是正确的，我的“帮助”类应该有与 EJB 相同的方法。那么我可以为帮助类重用EJB接口（即让帮助类实现与EJB相同的接口）吗？从建筑的角度来看，这不是很糟糕吗？

4

2 回答 2

1

我不认为

将方法调用委托给一些“帮助”类

, 意味着将 ejb 方法保留为仅调用帮助程序类的衬里。将实现委托给辅助类的目的是通过不同类型的服务公开者（ejb、pojo、Web 服务等）使用核心计算。这也有助于轻松地将服务从 ejb 移植到非 ejb。

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

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

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

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

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

于 2013-03-02T03:30:46.760 回答
1

我的同事告诉我，EJB 本身不应该包含任何方法实现，它只能将方法调用委托给一些“帮助”类

我认为你不会从中得到太多好处。为什么不将业务逻辑直接放在 EJB 中？老实说，我没有看到任何缺点。

像上面这样委托方法的原因是减少耦合代码（例如，当我想重用不在 EJB 上下文中的“帮助器”类的方法时）

您仍然可以拥有解耦的类并使用您的 EJB，而不仅仅是委派给辅助类。解耦更多地依赖于程序到接口和使用依赖注入，而不是委托给辅助类。

他还告诉业务方法不应该对 Java EE 有任何了解。

如果您使用@Stateless（它是 Java EE 的一部分）注释您的业务类 (EJB)，它们将不再与 Java EE 无关。

所以如果上面的陈述是正确的，我的“帮助”类应该有与 EJB 相同的方法。那么我可以为帮助类重用EJB接口（即让帮助类实现与EJB相同的接口）吗？从建筑的角度来看，这不是很糟糕吗？

从设计的角度来看，这没有任何意义，并且回到了简单地调用帮助类的虚拟 EJB 的问题上。

于 2013-03-02T01:35:58.593 回答