何时应该在Java应用程序中使用POJO (而不是EJB)？

Question

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

我想知道在什么情况下我应该创建一个类EJB，在什么情况下我应该使用一个通常的助手类。我读过使用EJB的好处。但是，在某些情况下，使用POJO更好吗？

Answer 1

EJB组件是由容器管理的，这意味着额外的开销。有一个反模式，叫做链锤，用于苍蝇

描述EJB (一种附带额外开销的技术)何时被选择而不是简单的POJO，在POJO中只需要轻量级处理。产生额外的复杂性；没有明显的好处

解决办法：

如果代码不使用以下容器服务，则使用POJO

• 并发性
• 实体交互
• 拦截器
• 生命周期管理
• 计时器
• 事务管理

我要补充的是，在许多情况下，EJB的使用类似于服务外观/服务。当您希望使用设计模式(CDI对象或POJOS)来处理业务逻辑，而不是仅仅使用EJB的过程方式时，就会出现真实的场景。重新措辞: EJB服务外观是解决复杂业务需求的设计模式的单一入口点(如果不需要设计模式，请不要使用它，保持简单！)

资料来源:飞锤，服务正面，服务：

OCM 6企业级架构师

真实世界的Java模式--反思最佳实践

Answer 2

简单地说，“除非您需要特定的EJB工具，否则总是如此”。

较长的答案如下。几年前，当使用EJB之前的3.0时，EJB是“沉重”的东西。您必须实现接口，从基类继承bean等等。EJB可以只在容器中使用。这意味着为EJB编写单元测试非常困难。

因此，人们使用了以下策略。在EJB需要时，他们在POJO中实现了所能实现的一切。解决方案是冗长的(因为有些东西是重复的)，但非常模块化和更好的可测试性。

自从EJB3.0被引入以来，POJO和EJB之间(几乎)没有区别。实际上，EJB是一个带有一些注释的POJO。这意味着您不必创建POJO，然后用瘦EJB层包装它。您可以实现类中的所有内容(如果需要，可以将其称为POJO )，然后使用注释将其转换为EJB。然而，由于委托是好的，所以更多的代码是EJB-注释-越少越好。