有人能解释一下 Enterprise Java Bean 和 Entity Java Bean 之间的区别吗？
我知道EJB是什么，但我不理解它们在持久性方面的区别。
我们使用相同的注释来保存它，但为什么称它为不同？
答案 0 :(得分：2)
在过去，随着地球的形成，Java EE有两种基本类型的Bean - 会话Bean和实体Bean。
会话Bean是某种内部服务的接口。大多数每个框架都与会话Bean有一些基本的并行。
实体Bean是由容器管理的持久元素。
当人们谈论Java EE时，特别是当他们抱怨它时，Entity Beans是一个核心问题。他们根本不是很好。
随着Java持久性架构（JPA）的引入，以及Hibernate和EclipseLink等框架，托管持久性的Java EE视图发生了巨大变化。我们不再拥有像Entity Beans这样的“重量级”构造，而是由JPA管理的轻量级POJO。
但是，混淆是由JPA管理的对象称为实体。 JPA实体和EJB实体Bean是完全不同的动物。但重用该术语是造成混淆的原因。
使用EJB实体Bean，EJB和实体是一回事。实体EJB是一个EJB，就像会话Bean一样。
然而，JPA实体不是。从技术上讲，实体根本与EJB无关。 JPA实体管理器集成在EJB运行时上下文中（并且通过投影，由该实体管理器管理的任何实体是EJB运行时上下文的一部分），但不要求在EJB容器中使用JPA。它们是独立的技术。也就是说，它们在EJB容器中运行良好。
所以
今天，实体EJB仍然存在，但已被弃用，并且有一天会消失。但容器仍然支持它们。除非你有一些遗留代码，否则没有理由付钱给他们。除了实体Bean之外，Java EE还支持：无状态会话Bean，有状态会话Bean和消息驱动Bean。这些都是一流的EJB，它们代表了Java EE组件模型的核心。 EJB在运行时最值得注意的方面是它们如何与容器内管理的本地事务空间进行交互。此外，EJB是EJB容器中的可部署构造，类似于WAR。 （它们也是其他东西，这几乎不详尽。）
JPA实体不是EJB。他们没有交易背景。他们有不同的状态，他们是否由他们的实体经理主动管理。实体管理器注册在本地事务空间中（因此JPA管理的实体也是代理）。
最后，随着CDI和注释的兴起，EJB直接嵌入到WAR中，区分EJB本身的界限每天都变得越来越模糊和模糊。