在这种情况下您真的需要无状态会话 bean 吗?
我们有一个项目,其中包含相当多的 EJB 2 无状态会话 bean,这些 bean 是很久以前创建的。 这些不是我们的客户端通过 RMI 访问的一线 bean,而是由该代码使用它们来执行特定功能。 然而,我开始相信将它们作为会话 bean 根本没有任何好处。
- 它们不需要通过以下方式访问 落基尔米。
- 他们不保留任何状态, 它们只是被分解的代码 从第一组豆子中取出 降低它们的复杂性。
- 他们不 有多个不同的 我们正在交换的实现 出来了,每一件都保持原样 年(除非错误修复和功能 补充)。
- 它们都不会改变 从调用它们的 bean 进入它们的事务 (也就是说他们不需要新的 交易,不参与 现有的,或以其他方式改变 事物)。
为什么这些不应该只是带有几个静态函数并且根本没有 EJB 陷阱的类?
We have a project with a pretty considerable number of EJB 2 stateless session beans which were created quite a long time ago. These are not the first-line beans which are accessed from our client via RMI, rather they are used by that code to perform specific functions. However, I've come to believe that there's nothing to be gained by having them as session beans at all.
- They do not need to be accessed via
RMI. - They do not retain any state,
they are just code that was factored
out of the first set of beans to
reduce their complexity. - They don't
have multiple different
implementations which we are swapping
out, each one has been as it was for
years (barring bug fixes and feature
additions). - None of them alter the
transaction that comes into them from the bean calling them
(that is they don't require a new
transaction, not participate in the
existing one, or otherwise change
things).
Why should these not all just be classes with a couple of static functions and no EJB trappings at all?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我能看到的唯一原因是出于集群目的(如果您正在进行集群)。 如果集群正确完成以分散负载,则可以将这些 bean 移交给另一台机器上的另一个虚拟机。
情况可能并非如此,向 EJB 的迁移只是过度设计。 我也正受此苦。
即使事务还不足以证明其合理性,您也可以使用单个 EJB 来处理事务并通过命令类型模式通过它调用不同的代码。
The only reason I can see is for clustering purposes (if you are doing clustering). That is the hand off to those beans could be on another VM on another machine if clustering is being done right to spread the load around.
That is likely not the case, and the movement to EJB's was just over-engineering. I'm suffering with that too.
Even transactions aren't really enough to justify it, you can have a single EJB that handles the transactions and call the different code through it via a Command type pattern.
似乎没有理由认为它们不应该是简单的 POJO 而不是无状态会话 Bean。 我想这也是人们以这种方式使用EJB 1.x之后得出的结论。
这也是 Spring 等框架作为 EJB 替代方案而存在的原因。
我想说将它们改为标准 POJO,但请确保您有一个单元和功能测试的安全网(对于 EJB 来说可能有点困难)来帮助您。
There seems to be no reason why they shouldn't just be simple POJO's rather than stateless session beans. I think this is the conclusion that people came to after using EJB 1.x in this manner as well.
It's also the reason why frameworks such as Spring exist as an alternative to EJB's.
I'd say change them over to be just standard POJO's, but make sure you have a safety net of unit and functional tests (which might be a little bit harder with EJB's) to help you.