Question

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

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

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

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

（如果以上陈述错误，请纠正我，请注意我们不使用JPA事务，我们使用另一个框架来处理数据持久性）

因此，如果上面的语句是正确的，我的“帮助器”类应该具有与EJB相同的方法。那么我可以为辅助类重用EJB接口（即使辅助类实现与EJB相同的接口）吗？从架构的角度来看，这不是很糟糕吗？

Answer 1

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

我认为你从它那里得不到多少好处。为什么不直接将业务逻辑放在EJB中？我没有诚实地看到任何缺点。

委托上述方法的原因是耦合较少代码（例如，当我想重用“helper”类的方法时在EJB上下文中）

您仍然可以使用分离的类并使用EJB，而不仅仅是委托给辅助类。解耦更多地取决于program to interfaces并使用依赖注入而不是委托给辅助类。

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

如果使用@Stateless（Java EE的一部分）注释业务类（EJB），它们将不再是Java EE不可知的。

所以如果上面的语句是正确的，那么我的“帮助者”类应该有与EJB相同的方法。所以我可以重用EJB接口来帮助类（即make helper类实现与EJB相同的接口）？不会从架构的角度来看，它会变坏吗？

从设计的角度来看，这没有意义，并且可以回到让虚拟EJB简单地调用辅助类的程度。

Answer 2

我不认为

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

，意味着将ejb方法保留为只调用辅助类的一个内联。将实现委托给辅助类的目的是使用不同类型的服务公开程序（ejb，pojo，web服务等）进行核心计算。这也有助于轻松地将服务从ejb移植到非ejb。

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

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

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

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