这看起来很明显,但我看到了相互矛盾的陈述:JPA是EJB 3.0的一部分吗?我不是专家,对我来说很困惑。
如果是这样,JPA会操纵Entity Beans?这些实体bean是持久层和使用无状态bean实现逻辑的业务层之间的接口吗?
我的基本问题是如何实现“基于各种标准搜索用户”功能,其中应该构建“搜索”请求 - 字符串表示?我的意思是,如果JPA不是EJB的一部分,我的bean应该不知道数据模型,对吧?
边界在哪里?
答案 0 :(得分:15)
JPA是EJB 3.0的一部分吗?
是和否...... 是因为声称实施EJB 3.0规范的每个应用程序服务器也必须提供JPA实现。 否因为JPA可以很容易地在EJB之外,在独立应用程序或Spring管理的应用程序中。
JPA操纵Entity Beans?
实体bean 在3.0之前的EJB中是一个可怕的想法。 JPA使用术语实体来区别于可耻的历史。但是,JPA实体是一种将数据库表映射到普通Java对象的方法。原则上,对对象的更改会传播到数据库,反之亦然(过度简化)。
正如我所说,JPA对EJB(被视为无状态和有状态会话bean)没有任何依赖性,反之亦然。但是没有什么能阻止你在EJB中使用JPA。
在您的场景中,您将拥有一个无状态EJB构建查询并通过JPA与数据库交互。从技术上讲,你将调用注入你的bean的EntityManager
上的方法:
@Stateless
public class SearchService {
@PersistenceContext
private EntityManager em;
public List<User> findUsersBornAfter(Date date) {
return em.
createQuery("SELECT u FROM User u WHERE u.birthDate > :birthDate ORDER BY name").
setParameter("birthDate", date).
getResultList();
}
}
正如您所看到的那样,业务层知道数据模型(显然),但就实体而言,不依赖于EJB /业务服务。在此示例中,JPQL(查询)在服务层中形成,User
是JPA实体。调用getResultList()
会导致JPA提供程序将JPQL转换为SQL,运行查询并将结果转换回User
对象实例。
EJB和JPA之间的边界现在是否清晰?
答案 1 :(得分:8)
几点说明:
答案 2 :(得分:3)
从维基百科 - Enterprise JavaBean中添加BalusC的答案:
请注意,当前的EJB 3.1规范没有详细说明应用程序服务器如何提供持久性(委托给JPA规范的任务),而是详细说明了业务逻辑如何轻松地与应用程序服务器提供的持久性服务集成。
集成消除了JPA的一些痛点,即相当冗长和嘈杂的启动和提交/回滚事务并确定extended persistence context
(最后一个仅用于有状态会话bean) )。
加入Bozho的回答:
答案 3 :(得分:1)
来自维基百科 - Java持久性API:
Enterprise JavaBeans
EJB 3.0规范(本身是Java EE 5平台的一部分)包含Java Persistence API的定义。但是,最终用户不需要EJB容器或Java EE应用程序服务器来运行使用此持久性API的应用程序。[1] Java Persistence API的未来版本将在单独的JSR和规范中定义,而不是在EJB JSR /规范中定义。 Java Persistence API取代了EJB 2.0 CMP(容器管理持久性)的持久性解决方案。