1

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

  • 它们不需要通过 RMI 访问。
  • 它们不保留任何状态，它们只是从第一组 bean 中提取出来的代码，以降低它们的复杂性。
  • 他们没有我们要换掉的多个不同的实现，每一个都像多年来一样（除非修复错误和添加功能）。
  • 它们都没有改变从调用它们的 bean 进入它们的事务（即它们不需要新事务，不参与现有事务，或以其他方式改变事物）。

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

4

2 回答 2

3

我能看到的唯一原因是出于集群目的（如果您正在进行集群）。如果集群正在正确地完成以分散负载，那么这些 bean 的移交可能会在另一台机器上的另一个 VM 上。

情况可能并非如此，转向 EJB 只是过度设计。我也为此感到痛苦。

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

于 2009-07-17T16:17:23.123 回答
1

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

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

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

于 2009-07-17T16:17:40.937 回答