MyEclipse6Java开发中文教程 在本章我们将会介绍JPA的开发,一共包括三部分内容:独立运行的JPA应用开发 Spring整合JPA开发;EJB査询语言开发。其实关于JPA还有一部分是基于EJB容器环境 的开发,那一部分内容我们将会放到后面的EJB开发一章来介绍。由于 MyEclipse6对JPA 开发提供了很方便的支持,因此我们的内容主要就集中在如何使用 MyEclipse进行快速开发 这个话题上。 131介绍 1311JPA简介 前面我们已经介绍了 Hibernate,但是实际在开发中所存在的这种进行数据库开发的 ORM框架不止一种,包括JDO,Bats, TopLink,KODo, OpenJPA等等多种开源的和 商业的产品。那么这有什么问题呢?假设现在我们的项目是用 Hibernate开发的,运行于 Oracle数据库之上,然而上线运行一段时间后,发现有一些性能上的问题,而这时候我们 想找人来做技术支持,希望它来帮我们解决这些问题,因为开发人员并不是个个都能读懂 Hibernate的源码然后找到问题所在的。这是第一种可能:客户(通常是有钱的大客户)希 望能在遇到问题时有人提供商业的技术支持和顾问服务。第匚种可能: Oracle公司推出了 专用于对 Oracle数据库特别优化过的ORM产品,名为 TopLink,然而很不幸,虽然它能解 决我们的问题,但是,因为 Hibernate的类库的包结构和 TopLink的相差太远,一个是以 org. hibernate开头的,另一个却是以 com. oracle开头的,更要命的是,两者之间的类库根 本就没有相似之处!那我们的项目并不能通过简单的将代码的包换一下,就能迁移成功,下 载岂不是要所有涉及 Hibernate的地方都得重写!换句话说,当我们使用 Hibernate或者其 它ORM框架开发时,我们的代码已经被绑死了!虽然代码是和数据库无关的,然而数据库 访问的Java代码却是死死的和某种框架绑定在一起了 针对这种情况,即Java的ORM框架再次出现诸侯割据,烽烟混战的局面,而Java 程序员却被迫只能选择一种框架,而无法在项目开发之后变更框架的情况,Sun公司- Java和 Java ee规范的领导者,就像在当年JDBC规范出现之前所作的那样,在 Java ee 5的规范制定中,特地提出了JPA( Java Persistence AP)这一新的ORM规范,意图结束这 种混乱的局面,并革命性的使用标注作为开发模式,很大程度上减少了开发人员的负担:包 括背诵包和类的负担以及辛辛苦苦的编写XML配置文件来进行实体映射的负担,并使用 POJO的方式进行开发。和之前的JDBC一样,在充分吸收现有ORM框架的基础上,得到 了一个易于使用、伸缩性强的ORM规范,它不仅仅提供基础的映射功能,还使这些JPA 的框架提供者能够提供高级功能。Sun引入新的 JPA ORM规范出于两个原因:其一,简化 现有 Java ee和 Java se应用的对象持久化的开发工作;其二,Sun希望整合对ORM技 术,实现天下归 JPA由EJB30软件专家组开发( Hibernate的发明者 Gavin King老师也加入其中), 作为JSR220实现的一部分。但它不局限于EJB30,你可以在Web应用、甚至桌面应用 中使用。JPA的宗旨是为POJO提供持久化标准规范,由此可见,经过这几年的实践探索, 能够脱离容器独立运行,方便开发和测试的理念已经深入人心了。目前 Hibernate3(确切 说是配合 Hibernate Entity Manager)、 TopLink、KODO以及 OpenJPA都提供了JPA的实 现,甚至还包括一些以前的JDO产品。而截至目前,所有支持 Java ee5的服务器(需要 通过Sun的认证才行),都支持JPA规范,这些服务器包括: Apache Geronimo-21(开源 服务器), WebLogic Server v10.0(商业,BEA公司产品,现并入 Oracle), IBM WASCE 2 刘长炯著MyEclipse 6 Java 开发中文教程 2 刘长炯著 在本章我们将会介绍 JPA 的开发，一共包括三部分内容：独立运行的 JPA 应用开发； Spring 整合 JPA 开发；EJB 查询语言开发。其实关于 JPA 还有一部分是基于 EJB 容器环境 的开发，那一部分内容我们将会放到后面的 EJB 开发一章来介绍。由于 MyEclipse 6 对 JPA 开发提供了很方便的支持，因此我们的内容主要就集中在如何使用 MyEclipse 进行快速开发 这个话题上。 13.1 介绍 13.1.1 JPA 简介 前面我们已经介绍了 Hibernate，但是实际在开发中所存在的这种进行数据库开发的 ORM 框架不止一种，包括 JDO，iBatis，TopLink，KODO，OpenJPA 等等多种开源的和 商业的产品。那么这有什么问题呢？假设现在我们的项目是用 Hibernate 开发的，运行于 Oracle 数据库之上，然而上线运行一段时间后，发现有一些性能上的问题，而这时候我们 想找人来做技术支持，希望它来帮我们解决这些问题，因为开发人员并不是个个都能读懂 Hibernate 的源码然后找到问题所在的。这是第一种可能：客户（通常是有钱的大客户）希 望能在遇到问题时有人提供商业的技术支持和顾问服务。第二种可能：Oracle 公司推出了 专用于对 Oracle 数据库特别优化过的 ORM 产品，名为 TopLink，然而很不幸，虽然它能解 决我们的问题，但是，因为 Hibernate 的类库的包结构和 TopLink 的相差太远，一个是以 org.hibernate 开头的，另一个却是以 com.oracle 开头的，更要命的是，两者之间的类库根 本就没有相似之处！那我们的项目并不能通过简单的将代码的包换一下，就能迁移成功，下 载岂不是要所有涉及 Hibernate 的地方都得重写！换句话说，当我们使用 Hibernate 或者其 它 ORM 框架开发时，我们的代码已经被绑死了！虽然代码是和数据库无关的，然而数据库 访问的 Java 代码却是死死的和某种框架绑定在一起了。 针对这种情况，即 Java 的 ORM 框架再次出现诸侯割据，烽烟混战的局面，而 Java 程序员却被迫只能选择一种框架，而无法在项目开发之后变更框架的情况，Sun 公司―― Java 和 Java EE 规范的领导者，就像在当年 JDBC 规范出现之前所作的那样，在 Java EE 5 的规范制定中，特地提出了 JPA(Java Persistence API)这一新的 ORM 规范，意图结束这 种混乱的局面，并革命性的使用标注作为开发模式，很大程度上减少了开发人员的负担：包 括背诵包和类的负担以及辛辛苦苦的编写 XML 配置文件来进行实体映射的负担，并使用 POJO 的方式进行开发。和之前的 JDBC 一样，在充分吸收现有 ORM 框架的基础上，得到 了一个易于使用、伸缩性强的 ORM 规范，它不仅仅提供基础的映射功能，还使这些 JPA 的框架提供者能够提供高级功能。Sun 引入新的 JPA ORM 规范出于两个原因：其一，简化 现有 Java EE 和 Java SE 应用的对象持久化的开发工作；其二，Sun 希望整合对 ORM 技 术，实现天下归一。 JPA 由 EJB 3.0 软件专家组开发（Hibernate 的发明者 Gavin King 老师也加入其中）， 作为 JSR-220 实现的一部分。但它不局限于 EJB 3.0，你可以在 Web 应用、甚至桌面应用 中使用。JPA 的宗旨是为 POJO 提供持久化标准规范，由此可见，经过这几年的实践探索， 能够脱离容器独立运行，方便开发和测试的理念已经深入人心了。目前 Hibernate 3（确切 说是配合 Hibernate Entity Manager）、TopLink、KODO 以及 OpenJPA 都提供了 JPA 的实 现，甚至还包括一些以前的 JDO 产品。而截至目前，所有支持 Java EE 5 的服务器（需要 通过 Sun 的认证才行），都支持 JPA 规范，这些服务器包括：Apache Geronimo-2.1（开源 服务器）， WebLogic Server v10.0（商业，BEA 公司产品，现并入 Oracle），IBM WASCE