我应该何时在Java EE应用程序中使用POJO（而不是EJB）？

Question

我正在学习JAVA EE。我使用oracle Java EE 7教程。根据本教程的第34.1.4节，他们在教程示例中使用了一些非EJB辅助类。 http://docs.oracle.com/javaee/7/tutorial/doc/ejb-basicexamples001.htm

我想知道在什么情况下我应该创建一个类EJB，在什么情况下我应该使用通常的帮助器类。我已经了解了使用EJB的好处。但是有没有使用POJO更好的情况？

Answer 1

简短的回答是“除非您需要特定的EJB工具”。

答案越长越好。 多年前，当使用EJB之前的3.0时，EJB是“沉重的”。你必须实现接口，从基类继承你的bean等。很简单，EJB只能在容器中使用。这意味着为EJB编写单元测试非常困难。

因此，人们使用以下策略。他们在EJB需要时在POJO中实现了所有可能的功能。解决方案很冗长（因为有些东西是重复的）但非常模块化且更易于测试。

自从引入EJB 3.0以来，POJO或EJB之间几乎没有区别。实际上，EJB是一个带有一些注释的POJO。这意味着您不必创建POJO，然后使用瘦EJB层将其包装起来。您可以在类中实现所有内容（如果需要，可以将其称为POJO），然后使用注释将其转换为EJB。仍然因为委托是好的，所以更多的代码是EJB注释 - 越少越好。

Answer 2

EJB组件（由容器管理）意味着一些额外的开销。有一个名为 Sledgehammer for a Fly 的反模式：

描述什么时候EJB是一种带有额外开销的技术，而不是简单的POJO，只需要轻量级处理。产生额外的复杂性;没有明显的好处

解决方案：

如果您的代码不使用以下容器服务，请使用POJO ：

• 并发
• 实体互动
• 拦截
• 生命周期管理
• 计时器
• 交易管理

我想补充一点，在很多情况下，EJB就像Service Facades / Services一样使用。当您想要使用设计模式（CDI对象或POJOS）处理业务逻辑而不是仅使用EJB以过程方式放置逻辑时，存在真实场景。重新定义：EJB服务外观是解决复杂业务需求的设计模式的单一入口点（如果您不需要设计模式，请不要使用它，保持简单！）。

资料来源：飞行大锤，服务门面，服务：

OCM Java EE 6 Enterprise Architect

Real World Java EE Patterns--Rethinking Best Practices