在这种情况下，你真的需要无状态会话bean吗？

Question

我们有一个项目，其中包含相当多的EJB 2无状态会话bean，这些bean是很久以前创建的。这些不是通过RMI从我们的客户端访问的第一行bean，而是由该代码用于执行特定功能。但是，我已经开始相信，将它们作为会话bean完全没有任何好处。

• 不需要通过它们访问它们 RMI。
• 他们不保留任何州， 它们只是被考虑的代码 从第一组豆到 减少它们的复杂性。
• 他们没有 有多种不同 我们正在交换的实现 出来，每个人都一如既往 年（除了错误修复和功能 增加）。
• 他们都没有改变 从调用它们的bean进入它们的事务 （也就是说，他们不需要新的 交易，不参与 现有的，或以其他方式改变 的东西）。

为什么这些不仅仅是具有几个静态函数且根本没有EJB陷阱的类？

Answer 1

我能看到的唯一原因是用于群集目的（如果你正在进行群集）。如果正在进行集群处理以扩散负载，那么那些bean可能会在另一台机器上的另一台虚拟机上运行。

情况可能并非如此，而且转向EJB的过程只是过度工程化。我也受苦了。

即使是事务也不足以证明它是合理的，你可以拥有一个处理事务的EJB，并通过命令类型模式通过它调用不同的代码。

Answer 2

似乎没有理由说他们不应该只是简单的POJO而不是无状态会话bean。我认为这是人们在以这种方式使用 EJB 1.x 之后得出的结论。

这也是为什么 Spring 等框架作为EJB的替代品而存在的原因。

我会说改变它们只是标准的POJO，但要确保你有一个安全网单元和功能测试（对于EJB来说可能有点困难）来帮助你。