企业Java Bean(EJB)和实体Java Bean之间的区别是什么?



谁能解释一下企业Java Bean实体Java Bean之间的区别?

我知道EJB是什么,但是我不理解它们在持久性方面的区别。

我们使用相同的注释来保存它,但是为什么调用它不同呢?

在过去,当地球形成时,Java EE有两种基本的Bean——会话Bean和实体Bean。

会话Bean是某种内部服务的接口。几乎每个框架都有一些基本的并行会话Bean。

实体Bean是由容器管理的持久元素。

当人们谈论Java EE,特别是当他们抱怨它的时候,实体bean是一个核心问题。他们只是不太好。

随着Java持久化体系结构(JPA)的引入,以及Hibernate和EclipseLink等框架的引入,托管持久化的Java EE视图发生了重大转变。我们不再拥有像实体bean这样的"重量级"构造,而是由JPA管理的轻量级pojo。

然而,令人困惑的是,由JPA管理的对象被称为实体。JPA实体和EJB实体Bean是完全不同的动物。但是这个术语的重复使用是混淆的来源。

使用EJB实体Bean, EJB和实体是一回事。实体EJB是一个EJB,类似于会话Bean。

然而,JPA实体不是。从技术上讲,实体与EJB完全没有关系。JPA实体管理器集成在EJB运行时上下文中(并且通过投影,由该实体管理器管理的任何实体都是EJB运行时上下文中的一部分),但是不要求JPA在EJB容器中使用。它们是不同的技术。也就是说,它们在EJB容器中确实工作得很好。

今天,实体ejb仍然存在,但已被弃用,并且总有一天会消失。但是容器仍然支持它们。除非您有一些遗留代码,否则没有理由为它们付出任何代价。除了实体Bean, Java EE还支持:无状态会话Bean、有状态会话Bean和消息驱动Bean。这些都是代表Java EE组件模型核心的第一类ejb。EJB在运行时最值得注意的方面是它们如何与容器内管理的本地事务空间交互。此外,EJB是EJB容器内的可部署构造,类似于WAR。(它们也是其他的东西,这很难穷尽。)

JPA实体不是ejb。它们没有事务上下文。至于它们是否由实体管理器主动管理,它们有不同的状态。实体管理器在本地事务空间中注册(因此JPA管理的实体也通过代理注册)。

最后,随着CDI和注解的兴起,将ejb直接嵌入到war中,区分ejb本身的边界每天都变得越来越模糊。

最新更新