毕业设计（论文）-基于ORM的JEE持久层实现.doc

基于ORM的JEE持久层实现摘要 随着人类社会的不断进步，计算机及Internet的日益普及；IT软件系统的复杂性不断地增加，其规模也在不断的扩大，对于灵活性、可靠性和个性化都提出了更高的要求；全球各行业的数据在急剧增加而且变得异常重要。这就给系统的设计、开发、维护带来了新的挑战：系统数据操作方式的选择。在现有的Web开发中，Java领域的OR Mapping的对象关系映射技术是一项重大的技术进步，在此基础上JEE平台出现了许多基于ORM的数据访问体系。传统J2EE体系的核心规范EJB有不小的缺陷，它对一般的Web应用显得过于笨重;特别是它的O/R映射解决方案EntityBean被证明是一个不成功的技术。为此，本文引入了JavaEE5中EJB3企业级组件以及它的数据访问组件JPA，详细描述JPA的ORM封装封装技术；同时引入开源ORM框架Hibernate，并详细描述Hibernate如何结合轻量级框架Spring实现JEE系统开发。关键词 ORM，JEE，Hibernate，SpringABSTRACT As human society De continuous progress, the increasing popularity of computer and Internet; IT software systems to the complexity of constantly increasing, the Guimo is also in constant Kuo Tai, for flexibility, reliability and a higher Ge Xing Du of the Yao Qiu; Global data on various industries and become abnormal in the dramatic increase in importance. This provides system design, development, maintenance has brought new challenges: the choice of system data mode of operation. In the existing Web development, Java OR Mapping the field of object-relational mapping technology is a major technological advances in this basis, there were many JEE platform data access system based on ORM. Traditional core specification EJB J2EE systems are not a small flaw, it seems the general Web application too heavy; particular, its O / R mapping solutions EntityBean proved to be an unsuccessful technique. Therefore, this paper introduces JavaEE5 in EJB3 components as well as its enterprise-class data access components JPA, a detailed description of the ORM package, packaging JPA; the same time the introduction of open-source ORM framework Hibernate, and a detailed description of how to combine the lightweight framework Spring Hibernate Implementation JEE system development.KEY WORDS ORM; JEE; Hibernate; Spring目录1.绪论51.1.研究背景51.2.研究的目的和意义61.2.1.研究的目的61.2.2.研究的意义71.3.目前已取得的研究成果71.3.1.JDBC71.3.2.ORM81.4.论文的组织结构102.ORM概述112.1.什么是ORM112.1.1.纯关系122.1.2.轻量对象映射122.1.3.中等对象映射122.1.4.完全对象映射122.2.一般的ORM问题132.3.为什么选择ORM143.Hibernate、EJB3和JPA简介163.1.1.理解标准163.1.2.Hibernate Core173.1.3.Hibernate Annotations173.1.4.Hibernate EntityManager184.基于ORM的JavaEE持久化服务Java Persistence API194.1.实体即POJO194.2.托管与非托管实体214.2.1.持久化上下文214.2.2.Transaction-scoped persistence context214.2.3.Extended persistence context224.2.4.游离实体(Detached entities)234.3.为PersistenceUnit打包244.4.Persistence Unit中的类集合264.5.获取EntityManager284.5.1.EntityManagerFactory284.5.2.在Java SE中获取EntityManager284.5.3.在Java EE中获取EntityManagerFactory294.6.获取persistence context304.7.操作EntityManager324.7.1.持久化实体334.7.2.查找实体344.7.3.查询364.7.4.更新实体364.7.5.合并实体374.7.6.删除实体384.7.7.refresh()394.7.8.contains()方法与 clear()方法394.7.9.flush()方法和 FlushModeType404.7.10.getDelegate()404.8.Resource Local 事务415.基于ORM的JavaEE携程列车信息系统的应用445.1.功能分析445.2.数据库设计445.2.1.数据库结构说明445.2.2.省份信息表-PROVINCE445.2.3.站点信息表-STATION445.2.4.列车信息表-TRAIN455.2.5.列车座位数量表-TRAINSEATNUM455.2.6.列车站点表-TRAINSTATION455.2.7.列车类型表-TRAINTYPE465.2.8.座位类别表-SEATTYPE465.2.9.售票信息表-SELLTICKET465.2.10.授权网点信息表-SITE465.3.功能实现475.3.1.车次查询的UML类图475.3.2.列车实体类代码Train.java475.3.3.站点实体类代码TrainStation485.3.4.站点类型实体类代码TrainType.java495.3.5.根据站点ID查询服务接口TrainIDService.java495.3.6.根据站点ID查询服务接口实现类TrainIDServiceImpl505.3.7.Spring的持久层配置文件persistence.xml505.3.8.Spring的实体事务管理声明配置文件bean.xml516.结论526.1.论文总结526.2.未来展望52参考文献54致谢551. 绪论1.1. 研究背景J2EE，Java2平台企业版（Java 2 Platform Enterprise Edition），是Sun公司为企业级应用推出的标准平台。 Java平台共分为三个主要版本JavaEE、JavaSE和JavaME。Sun公司在1998年发表JDK1.2版本的时候，使用了新名称Java 2 Platform，即Java2平台，修改后的JDK称为Java 2 Platform Software Developing Kit，即J2SDK。并分为标准版（Standard Edition，J2SE），企业版（Enterprise Edition，J2EE），微型版（MicroEdition，J2ME）。 J2EE便由此诞生。2005年6月，JavaOne大会召开，SUN公司公开JavaSE6。此时，Java的各种版本已经更名以取消其中的数字2：J2EE更名为JavaEE，J2SE更名为JavaSE，J2ME更名为JavaME。随着Java技术的发展，JavaEE平台得到了迅速的发展，成为Java语言中最活跃的体系之一。现如今，JavaEE不仅仅是指一种标准平台，它更多的表达着一种软件架构和设计思想。图1-1纵观 Java Platform， Enterprise Edition (Java EE) 规范的历史可以看出，每次重大修订都是由一个重要主题推动的。例如，第一次发布 J2EE 1.2 时，伴随的重要主题是首次将单独的规范绑定在一起，后来，在 J2EE 1.4 中，关注的重要主题则是 Web 服务。上下图显示了 JavaEE 的摘要历史，列出了每个版本的重要功能以及促成每次修订的一些重要外部影响。与一些新技术的大多数早期版本一样，JavaEE规范的以前版本中存在一些“难点”，其中包括：1) 业务逻辑编程的复杂性。2) 持久性编程模型的复杂性和性能。3) 表示层/逻辑混合。4) Web 服务的类型、复杂性、文档模型、扩展和性能。5) 多成员团队开发。6) 漫长的编辑-编译-调试周期。这时，毫无疑问，JavaEE5规范的主题就是简化，这一目标已通过改善以下领域的开发体验得到实现：(1)简化业务逻辑开发。(2)简化测试和依赖关系管理。(3)简化 O/R 持久性。(4)增强 Web 服务编程模型。JavaEE5 中的许多升级都受到商业和开放源代码领域创新技术的影响，例如 Hibernate、Spring、Service Data Object (SDO) 以及其他技术。另外，还预期对规范的级别进行升级，做一些小幅度的改进。1.2. 研究的目的和意义1.2.1. 研究的目的到目前为止，企业应用都需要有RDBMS的支持，数据是企业业务的核心。在Java/JavaEE平台中，为操控RDBMS，开发者必须借助JDBC API完成各种CRUD操作。但是，并不是所有的应用都会直接采用JDBC API与RDBMS进行交互，ORM技术的出现使得开发者有了更多的选择。为了简化企业级Java应用程序开发，JavaEE以及Spring框架提供了高效的数据访问层。JavaEE主要以EJB3作为核心模块，为我们提供了处理业务逻辑的会话Bean以及数据处理的实体Bean，其中实体Bean部分主要由JPA完成，JPA提供了数据库资源链接以及数据持久操作等各项功能。Hibernate在企业级应用中通常配合轻量级Spring框架使用，Spring在Core核心模块和AOP模块的基础上，为我们提供了完备的数据访问的抽象和集成服务，为各种当前业界流行的ORM产品提供了形式统一的集成支持。本论文内容将对JavaEE规范中EJB3处理逻辑的过程中如何使用JPA进行数据操作以及如何使用遵循JavaEE规范的Spring框架集成Hibernate进行数据访问，全方位了解当前的Java/JavaEE中的ORM数据访问的企业应用。1.2.2. 研究的意义目前，“全球一体化”的浪潮席卷全球，而且“全球化”和“网络化”紧密联系在一起的，使得全球的信息高速公路得以快速发展。随着Internet在全世界的拓展，高速、高效、安全的数据信息成为企业业务生存与发展的根基。2009年IBM公司提出了“智慧地球”的创新理念，利用高质量的企业应用软件构建智慧的各行各业，从而形成智慧的地球；并且在当年也提出，世界到达2010年，全球30%的数据都是医疗数据，从这方面也能让我们了解到全球的数据在庞大，那么如何保证我们这些重要数据的存储、访问以及高效的管理成为了一个大难题。那么，高速、高效的全球数据信息成为了必然。当前，世界仍然处于“金融危机”时刻，企业的生存、发展仍然相当困难。业务发展是每一个企业生存的根基，那么如何能够在金融危机的大环境下突围而出，成为行业的领导者，高效的业务数据信息肯定是必然。因此，构建企业级应用程序的过程中，如何能够使得企业软件中数据的高效交互变得非常重要。当前使用JavaEE规范的EJB3构建企业级应用程序以及基于Spring开源框架构与Hibernate建Java/JavaEE应用程序的企业也来也多，通过研究JavaEE对数据访问模块的支持，对企业应用程序中数据访问层的设计、开发、维护具有重要意义。同时也能够对JavaEE以及Spring框架数据访问层有详细的认识，促进Java技术的发展。1.3. 目前已取得的研究成果1.3.1. JDBCJDBC（Java Data Base Connectivity）是一种用于执行SQL语句的Java API，可以为多种关系数据库提供统一访问，它由一组用Java语言编写的类和接口组成。JDBC为工具/数据库开发人员提供了一个标准的API，据此可以构建更高级的工具和接口，使数据库开发人员能够用纯 Java API 编写数据库应用程序，同时，JDBC也是个商标名。有了JDBC，向各种关系数据发送SQL语句就是一件很容易的事。换言之，有了JDBC API，就不必为访问Sybase数据库专门写一个程序，为访问Oracle数据库又专门写一个程序，或为访问Informix数据库又编写另一个程序等等，程序员只需用JDBC API写一个程序就够了，它可向相应数据库发送SQL调用。同时，将Java语言和JDBC结合起来使程序员不必为不同的平台编写不同的应用程序，只须写一遍程序就可以让它在任何平台上运行，这也是Java语言“编写一次，处处运行”的优势。Java数据库连接体系结构是用于Java应用程序连接数据库的标准方法。JDBC对Java程序员而言是API，对实现与数据库连接的服务提供商而言是接口模型。作为API，JDBC为程序开发提供标准的接口，并为数据库厂商及第三方中间件厂商实现与数据库的连接提供了标准方法。JDBC使用已有的SQL标准并支持与其它数据库连接标准，如ODBC之间的桥接。JDBC实现了所有这些面向标准的目标并且具有简单、严格类型定义且高性能实现的接口。Java 具有坚固、安全、易于使用、易于理解和可从网络上自动下载等特性，是编写数据库应用程序的杰出语言。所需要的只是 Java应用程序与各种不同数据库之间进行对话的方法。而 JDBC 正是作为此种用途的机制。JDBC 扩展了 Java 的功能。例如，用 Java 和 JDBC API 可以发布含有 applet 的网页，而该 applet 使用的信息可能来自远程数据库。企业也可以用 JDBC 通过 Intranet 将所有职员连到一个或多个内部数据库中（即使这些职员所用的计算机有 Windows、 Macintosh 和UNIX 等各种不同的操作系统）。随着越来越多的程序员开始使用Java 编程语言，对从 Java 中便捷地访问数据库的要求也在日益增加。1.3.2. ORM对象关系映射（Object Relational Mapping，简称ORM）是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术。 简单的说，ORM是通过使用描述对象和数据库之间映射的元数据，将Java程序中的对象自动持久化到关系数据库中。本质上就是将数据从一种形式转换到另外一种形式。 这也同时暗示者额外的执行开销；然而，如果ORM作为一种中间件实现，则会有很多机会做优化，而这些在手写的持久层并不存在。 更重要的是用于控制转换的元数据需要提供和管理；但是同样，这些花费要比维护手写的方案要少；而且就算是遵守ODMG规范的对象数据库依然需要类级别的元数据。ORM是随着面向对象的软件开发方法发展而产生的。面向对象的开发方法是当今企业级应用开发环境中的主流开发方法，关系数据库是企业级应用环境中永久存放数据的主流数据存储系统。对象和关系数据是业务实体的两种表现形式，业务实体在内存中表现为对象，在数据库中表现为关系数据。内存中的对象之间存在关联和继承关系，而在数据库中，关系数据无法直接表达多对多关联和继承关系。因此，对象-关系映射(ORM)系统一般以中间件的形式存在，主要实现程序对象到关系数据库数据的映射。面向对象是从软件工程基本原则(如耦合、聚合、封装)的基础上发展起来的，而关系数据库则是从数学理论发展而来的，两套理论存在显著的区别。为了解决这个不匹配的现象，对象关系映射技术应运而生。一般的ORM包括以下四部分：1) 一个对持久类对象进行CRUD操作的API；2) 一个语言或API用来规定与类和类属性相关的查询；3) 一个规定mapping metadata的工具；4) 一种技术可以让ORM的实现同事务对象一起进行dirty checking， lazy association fetching以及其他的优化操作。目前众多厂商和开源社区都提供了持久层框架的实现，常见的有：1) Apache OJB （/ojb/）2) Cayenne （/cayenne/）3) Jaxor （）4) Hibernate （）5) iBatis （）6) jRelationalFramework （）7) mirage （/en/oss/mirage/toon）8) SMYLE （http:/www.drjava.de/smyle）9) TopLink （/products/ias/toplink/index.html）其中 TopLink 是 Oracle 的商业产品，其他均为开源项目。Hibernate 的轻量级 ORM 模型逐步确立了在 Java ORM 架构中领导地位，甚至取代复杂而又繁琐的 EJB 模型而成为事实上的 Java ORM 工业标准。而且其中的许多设计均被 J2EE 标准组织吸纳而成为最新 EJB 3.0 规范的标准，这也是开源项目影响工业领域标准的有力见证。JavaEE5中的Persistence API几乎完全采纳了Hibernate的ORM实现思路，通过javax.persistence这样的包前缀，ORM JPA成为了JavaEE中持久技术的主流。1.4. 论文的组织结构1) 第一章：绪论：对本文研究的背景、目的、意义以及主要研究内容和当前成果进行阐述。2) 第二章：ORM概述：首先对ORM思想概念进行详细的阐述。然后提出ORM当前能够解决的问题以及存在的缺陷问题，最后描述如何在项目技术上选择合适的ORM解决实际问题。3) 第三章：Hibernate、EJB2和JPA简介：详细阐述了在Java EE规范下，EJB3中如何融入了JPA作为持久技术，并且讨论JPA在Java EE项目中的实践所需的Hibernate组件。4) 第四章：基于ORM的Java EE持久化服务JPA：本章详细描述了Java EE规范下，如何采用EJB + JPA的结合，设计符合标准的Java EE应用程序。5) 第五章：基于Java EE规范的开源ORM-Hibernate：本章内容主要以开源ORM框架Hibernate为基础，详细描述了Java EE项目实践中，如何采用Hibernate作为数据持久化服务。6) 第六章：ORM在Java EE携程列车信息系统的应用：本章内容主要以实际的项目开发作为研究示例，展示ORM技术的应用。7) 第七章：结论：对论文的研究成果进行了自我总结和评价，进一步明确了我们在相关领域的研究成果和贡献。同时总结了我们的研究中的不足和缺陷。最后针对Java EE规范的子规范ORM技术的发展提出自己的愿望与要求。2. ORM概述2.1. 什么是ORM简而言之，ORM就是利用描述对象和数据之间映射的元数据，自动（且透明）地把Java应用程序中的对象持久化到关系数据库中的表。ORM本质上是把数据从一种表示法(可逆)转换为另一种表示法进行工作。这意味着某些性能损失。然而，如果ORM作为中间件实现，就有许多手工编码的持久层所没有的优化机会。控制转换的元数据的规定和管理在开发时增加了企业日常开支，但是其成本却不少于维护一个手工编码的解决方案所需的成本。常见问题:ORM难道不是一个Visio插件吗？首字母缩写的ORM也可以是对象角色建模(Object Role Modeling)的意思，且这个术语出现在相关的ORM之前，它描述了一种在数据库建模中使用的信息分析方法，主要由Microsoft Visio(一种图形化建模工具)支持。数据库专家们用它作为最普及的实体-关系建模(Entity-Relationship Modeling)的替代或者补充。然而，如果你和Java开发人员谈ORM，通常是在ORM的环境中。ORM的解决方案包含下面的4个部分：1) 在持久化的对象上执行基本的CRUD操作的一个API；2) 用于指定引用类型或者类属性的查询的一种语言或者API；3) 用于指定映射元数据的一种工具；4) 用于实现ORM的一项技术，与事务对象交互，执行脏检查(dirty checking)、延迟关联抓取以及其他优化功能。我们使用完整的ORM术语，包括从一个基于元数据的描述中自动产生SQL的任何持久层。我们不包括开发人员用JDBC手工编写SQL来手动解决ORM问题的持久层。使用ORM，应用程序与ORM API和领域模型驱动类交互，并从底层的SQL/JDBC中被抽象出来。依赖于这些特性或者特定的实现，ORM引擎也可能承担乐观锁(optimistic locking)和高速缓存这类问题，完全免去了应用程序对这些问题的关注。Mark Fussel(Fussel，1997)，ORM领域的一位开发人员，定义了下列4个ORM质量等级。我稍微改写了他的描述，并把它们放在当今Java应用程序开发的上下文中。2.1.1. 纯关系整个应用程序(包括用户界面)都围绕着关系模型和基于SQL的关系操作而设计。这种方法，除了它不足于用于大型系统之外，对于那些容许低级代码重用的简单应用程序来说，它不失为一种极好的解决方案。直接的SQL可以在各个方面进行调优，但是缺点(例如缺乏可移植性和可维护性)也是很显著的，尤其对长期运行而言。这类应用程序经常大量地使用存储过程，把一些工作从业务层转移到了数据库中。2.1.2. 轻量对象映射实体被表示为手工映射到关系的类。使用众所周知的设计模式，把手工编码的SQL/JDBC从业务逻辑中隐藏起来。这种方法非常普遍，对于那些带有少量实体的应用程序，或者那些使用普通的元数据驱动的数据模型的应用程序来说，它是很成功的。存储过程在这种类型的应用程序中可能也有一席之地。2.1.3. 中等对象映射这种应用程序围绕对象模型而设计，SQL使用一个代码生成的工具在创建时产生，或者通过框架代码在运行时产生的。对象之间的关联得到持久化机制的支持，并且查询使用一种面向对象的表达方式语言方式来指定。对象由持久层高速缓存。ORM产品和自制的持久层都至少支持这一级别的功能。它非常适合一些复杂事物的中等规模的应用程序，特别是在不同的数据库产品之间的可移植性很重要的时候。这些运用程系通常不使用储存过程。2.1.4. 完全对象映射完全的对象影射支持的对象模型：组合、继承、多态和可达的持久化。持久层实现了透明的持久化；持久化类不必继承任何特殊的基类，或者实现特殊的接口高效的抓取策略（延迟、即时和预取）和高速缓存策略被透明地实现到应用程序。这一级别的功能无法实现通过自制的持久层实现它相当于几年的开发时间。许多商业和开源的Java ORM工具已经实现了这个质量等级。这个等级符合本书中使用的ORM定义。来看一下希望通过实现完全对象映射的一个工具能够得以解决的一些问题。2.2. 一般的ORM问题下列问题(称作ORM问题)列表标识了Java环境中被完全的ORM工具解决的一些根本问题。特别的ORM工具可能提供额外的功能(例如积极告诉缓存)，但这是个相当详尽的概念问题和特定于ORM问题的列表。1) 持久化类看起来什么样？持久化工具有多透明？我们必须对业务领域的类采用编程模型和惯例吗？2) 映射元数据如何定义？由于对象/关系转换完全由元数据控制，这个元数据的格式和定义很重要。ORM工具应该提供图形化用户界面(GUI)以便图形化地处理元数据吗？或者对于元数据的定义有没有更好的方法？3) 对象同一性和等同性如何与数据库(主键)同一性相关？如何映射特定类的实例到特定表的行？4) 应该如何映射类继承层次结构？有几种标准的策略。多态关联、抽象类和接口怎么样呢？5) 持久化逻辑如何在运行时与业务领域的对象交互？这是个一般的编程问题，并且有许多解决方案，包括源代码生成、运行时反射、运行时字节码生成和创建时字节码增强。这个问题的解决方案可能影响你的构建过程(但宁可如此，因为影响构建过程总好过影响用户)。6) 什么是持久化对象的生命周期？有些对象的生命周期取决于其关联对象的生命周期吗？如何把一个对象的生命周期转变为一个数据库行的生命周期？7) 提供什么工具来排序、搜索和统计？应用程序可以在内存中处理其中一些事情，但是为了有效地使用关系技术，经常需要由数据库来完成这项工作。8) 如何利用关联有效地获取数据？对关系型数据的有效访问通常经由表连结来完成。面向对象应用程序通常通过导航对象网络来访问数据。如果可能，这两种数据访问模式应该避免：n+1查询问题和它的补充笛卡尔积问题（在单个查询中抓取太多的数据）。在一个ORM工具的设计和架构上强加基础约束的另外两个问题，对于任何数据访问技术都是共通的：1) 事务和并发性；2) 高速缓存管理(和并发性)。如你所见，一个完全的ORM工具需要处理一个相当长的问题列表。现在为止，你应该开始体会到ORM的价值了。2.3. 为什么选择ORMORM的实现非常复杂，虽然没有应用程序服务器复杂，却比Web应用程序框架如Struts或者Tapestry要复杂得多。为什么要把两一个复杂得基础元素引入到我们的系统中呢？值得这么做吗？ORM一个假定的益处是使开发人员避免杂乱的SQL。持这种观点的人认为不能期待面向对象的、开发人员很好地理解SQL或者关系数据库，并且他们认为SQL有点讨厌。正好相反，我们认为Java开发人员必须足够熟悉并欣赏关系模型和SQL，以便用ORM进行工作。ORM是一项高级的技术，将被为其付出艰辛努力的开发人员所用。要有效地使用ORM工具，必须能够观察和解读它生成的SQL语句，并理解对于其性能的含义。现在，来看看当前业界的ORM工具Hibernate、JPA等的一些益处：1) 生产力与持久化相关的代码可能会是Java应用程序中最冗长乏味的代码。ORM工具去除了许多琐碎的工作(比你想象的更多)，并让你把精力集中在业务问题上。无论你喜欢哪种应用程序开发策略自顶向下，从一个领域模型开始；或者自底向上，从一个现有的数据库Schema开始ORM适当的工具一起使用，讲明显减少开发时间。2) 可维护性更少的代码行(LOC)使得系统更易于理解，因为它强调业务逻辑基于那些费力的基础性工作。最重要的是，系统包含的代码越来越少则越易于重构。自动的对象/关系持久化充分地减少了LOC。当然，统计代码行是衡量应用程序复杂性的一种有争议的方式。然而，ORM应用程序更易于维护还有其他原因。在手工编码的持久化系统中，关系表示法和对象模型实现领域之间存在着一种必然的压力。改变一个，通常都要改变另一个，并且一个表示法设计经常需要妥协以便适应另一个存在。(在实际应用程序中，通常是领域的对象模型发生妥协。)ORM提供了两个模型之间的一个缓冲，允许面向对象在Java方面进行更优雅的利用，并且每个模型的微小变化都不会传递到另一个模型。3) 性能一种普通的断言是，手工编码的持久化与自动的持久化相比总是至少可以一样快，并且经常更快。这是真的，就像汇编代码总是至少可以与Java代码一样快，或者手工编写的解析器总是至少可以与由YACC或者ANTLR产生的解析器一样快，这同样是真的一样换句话说，这有点离题了。这种断言的言下之意是，手工编码的持久化在实际应用程序中将至少完成得一样好。但是，这种含义只有当实现至少一样快的手工编码的持久化所需的努力，类似于使用自动的解决方案所付出的努力时才是对的。真正值得关注的问题是，当我们考虑到时间和预算的约束时会发生什么？给定一项持久化任务，有多种优化可能。有些(例如查询提示)用手工编码的SQL/JDBC更容易实现。然而，大部分优化用自动的ORM则更容易实现。在有时间限制的项目中，手工编码的持久化通常允许你进行一些优化。Hibernate始终允许使用更多的优化。此外，自动的持久化把开发人员的工作效率提高了那么多，使得开发人员能够花更多的时间对其他的少量瓶颈进行手工优化。最后，实现你的ORM软件的人，可能比你更有时间研究性能优化问题。例如，你知道高速缓存PreparedStatement实例给DB2 JDBC驱动带来明显的性能提升，去破坏了InterBase JDBC驱动吗？你认识到只更新表中被改变的列对于有些数据库会明显变快，却潜在地减慢了其他的数据库吗？在你手工编写的解决方案中，试验这些不同策略之间的冲突容易吗？4) 供应商独立性ORM从底层的SQL数据库和SQL方言中把应用程序抽象出来。如果这个工具支持许多不同数据库(大部分都支持)，那么这会给你的应用程序带来一定程度的可移植性。你不必期待一劳永逸(一次编写/到处运行)，因为数据库的能力各异，实现完全的可移植性将需要牺牲这个更强大平台的一些优势。然而，用ORM通常更容易开发跨平台的应用程序。即时你不需要跨平台操作，ORM仍然可以帮助减少一些被供应商锁定的风险。此外，数据库独立性在这种开发场景中也有帮助开发人员在开发时使用轻量级的本地数据库，但实际的产品部署在不同的数据库上。3. Hibernate、EJB3和JPA简介Hibernate、EJB3以及JPA都是基于JavaEE规范而设计的。Hibernate是一个完全的ORM工具，提供前面列举的所有ORM的益处。在Hibernate中使用的API是原生的，并且是由Hibernate的开发人员设计的。对于查询接口和查询语言，以及ORM元数据如何定义，这也是一样的。在使用Hibernate开始项目之前，应该考虑EJB3.0标准和它的子规范Java Persistence。让我们回顾历史看看这个新标准是如何产生的。许多Java开发人员认为EJB2.1实体bean是持久层实现的技术之一。EJB编程和持久化模型在行业中已经被广泛采用，并且已经成了J2EE(或者现在称作JavaEE)成功的一个重要因素。然而，过去几年中，开发人员社区中的EJB批评家的声音却越来越大(特别有关实体bean和持久化)，一些公司认识到应该改进EJB标准。Sun，作为J2EE的倡导者，启动了一个新的Java规范要求(JSR)，目标是简化EJB。这个新的JSR，EJB3.0(JSR220)，引起了很大的关注。来自Hibernate团队的开发人员加入了早期的专家组，帮助制定出新规范的雏形。新标准的一个重要决定是，指定和标准化实际应用程序中有用的东西，借鉴现有成功的产品和项目的思想和理念。因此，Hibernate作为一个成功的数据持久化解决方案，在新标准的持久化部分扮演了重要角色。3.1.1. 理解标准新的EJB3.0规范有几个部分：第一部分给会话bean、消息驱动bean以及部署规则等，定义新的EJB编程模型。规范的第二部分专门处理持久化：实体、ORM元数据、持久化管理器接口和查询语言。第二部分被称作JPA，可能因为它的借口是在javax.persistence包中。JavaEE5的新标准设计了两条重要的原则：1) JPA引擎应该是可插拔的，这意味着如果你不满意，应该能够从中取出一种产品并用另一种代替即使你要保留相同的EJB3.0容器或者JavaEE5.0应用程序服务器。2) JPA引擎应该能够在EJB3.0(或者任何其他)运行时环境之外运行，而简单的标准Java中不需要容器。这种设计的结果是，开发人员和结构师有了更多的选择，这样带动了竞争，因此提高了产品的整体质量。当然，实际的产品也提供超出规范的特性，作为特定于供应商的扩展(例如：性能调优，或者因为供应商关注一个特定的垂直的问题领域)。Hibernate实现Java Persistence，并且由于JPA引擎必须是可插拔的，新的和值得关注的软件结合成为可能。可以从不同的Hibernate软件模块中选择，并根据项目的技术和业务需求把它们结合起来。3.1.2. Hibernate CoreHibernate Core也称作Hibernate3.2.x或者Hibernate。它是持久化的基础服务，带来原生的API和它存在在XML文件中的映射元数据。它有一种查询语言称作HQL（与SQL几乎相同），以及用于Criteria和Example查询的可编程查询接口。对于每个东西都有几百种选项和特性可用，因为Hibernate Core真正是所有其他模块创建的基础和平台。Hibernate Core也可以单独使用，独立于任何框架或者任何包含所有SDK的特定运行时环境。它适用于每一个JavaEE/J2EE应用程序服务器、Swing应用程序、简单的servlet容器等。只要你能够给Hibernate配置数据源，它就能够实现。应用程序代码将使用Hibernate API和查询，并且你的映射元数据编写在原生的Hibernate XML文件中。3.1.3. Hibernate AnnotationsJDK5.0提供了定义应用程序元数据的一种新方法：类型安全的注解直接嵌入到Java源代码中。许多Hibernate用户已经熟悉这个概念，就像XDoclet软件在编译时支持Javadoc元数据属性和预处理程序一样。使用Hibernate Core顶部的Hibernate Annotations包，现在可以使用类型安全的JDK5.0元数据作为原生的Hibernate XML映射文件的替代或者补充。一旦见过与Hibernate XML映射文件并排的映射注解时，你会发现它的语法与语义很常见。然而，基础注解不是私有的。JPA规范定义ORM元数据语法与语义，主要机制为JDK5.0注解。Hibernate Annotations一般来说是实现JPA标准的一组基础注解，它们也是更高级的和更奇异的Hibernate映射和调优所需的一组扩展注解。可以使用Hibernate Core和Hibernate Annotations减少映射元数据的代码行，相比于原生的XML文件，可能更喜欢注解更易重构的能力。如果完整的可移植性不是你最关注的，则可以只用JPA，或者增加一个Hibernate扩展注解。3.1.4. Hibernate EntityManagerJPA规范也定义编程接口、持久化对象的生命周期规则和查询特性。JPA这部分的Hibernate实现可被用作Hibernate EntityManager，这是另一个可以堆在Hibernate Core顶部的可选模块。当需要简单的Hibernate接口或者甚至需要JDBC连接时，可以退回。Hibernate原生的特性在各个方面都是JPA持久化特性的一个超集。(简单的事实就是，Hibernate EntityManager是对提供JPA兼容性的Hibernate Core的一个小包装。)使用标准化的接口和标准化的查询语言有个好处：可以使用任何EJB3.0兼容应用程序服务器执行JPA兼容的持久层。或者，可以在简单的Java中任何特定的标准运行时环境之外使用JPA(这是Hibernate Core可以被用在任何地方的真正含义)。Hibernate Annotations应该与Hibernate EntityManager结合考虑。如果你针对JPA接口使用JPA查询编写应用程序代码，而没有用JPA注解创建大部分映射，这是不正常的。4. 基于ORM的JavaEE持久化服务Java Persistence APIJPA(Java Persistence API，Java持久化API)是Sun于JavaEE5之后提出的ORM解决方案的统一标准，具体实现由不同提供商支持，包括Hibernate、Toplink等。就好像当年的JDBC标准一样，只不过，JPA是面向ORM的统一。JPA提供一种标准的OR映射解决方案，该解决方案完全集成到EJB3。0兼容的容器中。JPA已经作为一项对象持久化的标准，不但可以获得Java EE应用服务器的支持，还可以直接在Java SE中使用。持久化服务时JavaEE平台的关键部分。在旧版本的JavaEE中，EJB规范涵盖了持久层的相关内容，而在JavaEE5中，持久层已经被剥离出来，成为一个独立的规范，Java Persistence 1.0。持久化服务在JDBC之上提供了一层易于使用的抽象，它使你的代码可以与各种数据库、厂商专有特性以及针对性的优化相隔离。它还是一个对象，/关系映射引擎，这意味着，Java Persistence API可以自动完成Java对象与关系数据库之间的映射。除此之外，持久化服务还提供了一种酷似SQL的查询语言，只是为了更适合于操纵Java对象，经过了一定的裁剪。在新的Java Persistence规范中，EntityManager是为所有持久化操作提供服务的中枢。实体就如其他Java对象一样，纯属普通的Java对象，知道你的代码中显示地调用EntityManager将实体持久化后，它们才会变成持久化对象。EntityManager在一组固定的实体类与底层数据源之间进行O/R映射的管理，它提供了创建、查找、同步对象以及将对象插入数据库的API，它还提供了对象缓存，并在一个像JTA这样的JavaEE环境中对entity bean与事务性服务之间的交互进行控制。虽然EntityManager是与裕JavaEE以及EJB紧密结合一起的，但是EntityManager并非仅限于在这种环境下使用，我们同样可以在普通的Java程序中使用它。4.1. 实体即POJO在Java Persistence 规范中，实体即普通的Java对象(POJO)。和其他普通Java对象一样，你只需要使用new()运算符就可以为其分配内存。不过，直到与EntityManager关联，entity bean class的实例才会变成编程持久对象。Customer实体的简单例子：import javax.persistence.Entity;import javax.persistence.GeneratedValue;import javax.persistence.Id;Entitypublic class Customer private int id;private String name;IdGeneratedValuepublic int getId() return id;public void setId(int id) this.id = id;public String getName() return name;public void setName(String name) = name;假如我们调用new()为Customer类的实例分配内存，不会有任何奇迹出现。New运算符不会通过某个神秘的底层服务在数据库中持久化Customer类的实例。Customer cust = new Customer();Cust.setName(“Bill”);创建好的Customer实例仍会是POJO，直到你请求EntityManager在数据库中创建对应的实体为止。4.2. 托管与非托管实体在进一步研究讨论entity manager服务之前，我们需要更加深入地理解实体对象实例的生命周期。一个entity bean实例或者受entity manager托管，或者不受其托管。若entity bean与EntityManager相关联，则EntityManager会跟踪实体的状态变更，并在entity manager决定对实体状态进行flush操作的时候，将这些变更保存到数据库中。一旦实体被解除了关联，它就不再受托管了。Entity Manager不会对任何解除关联的实体做状态变更的跟踪。4.2.1. 持久化上下文Persistence Content 是由一组受托管的实体对象实例所构