使用Hibernate和Spring开发数据持久层-毕业论文

使用Hibernate和Spring开发数据持久层本科毕业论文(科研训练、毕业设计)题 目：使用Hibernate和Spring开发数据持久层姓 名：学 院：软件学院专 业：软件工程年 级： 学 号：指导教师(校外)： 职称： 指导教师(校内)： 职称： 年 月 日使用Hibernate和Spring开发数据持久层摘 要 在现今世界中，数据已经是信息时代中的重心，本系统基于对象/关系映射的核心理论，使用Hibernate持久层技术和Spring框架构建数据持久层，优化数据库交互，搭建原型机系统。通过实践证明了Hibernate的优秀，以及Spring架构的先进性。关键词 持久层 ORM Hibernate SpringABSTRACT Nowadays, the Data has been the most important thing in this communication epoch. The design is based on Object/Relation Mapping theory, using Hibernate persistent technology and Spring framework to construct a data persistence layer, optimize the database interaction, construct a archetype system. From this design, proving the excellence of Hibernate and the advance of Spring framework.Keyword Persistence Layer ORM Hibernate Spring目 录中文摘要Abstract第一章引言11.1课题背景11.2设计意图11.3设计概述21.4论文组织3第二章基础概念42.1 ORM42.1.1 ORM概念42.1.2 ORM的好处52.2 Hibernate52.2.1 JDBC和Hibernate52.2.2 新技术Hibernate82.2.3 Hibernate特性82.3 Spring框架92.3.1 Spring特性92.3.2 Spring中的IOC102.4 本章小结12第三章设计方案和实现133.1 设计方案概述133.2 IDE开发工具133.3 构建持久层对象153.4 映射描述183.5 Hibernate语义233.6 整合253.6.1整合配置253.6.2数据访问273.6.3 原型机系统293.7 本章小结31第四章结论32致 谢 语33参 考 文 献343第一章 引言1.1 课题背景在现今软件世界里，由于功能和数据量的增长，数据库扮演了越来越重要的作用，可以说基本上任何一个软件都不可能脱离数据库单独存在。数据库技术的发展，已经成为先进信息技术的重要组成部分，是现代计算机信息系统和计算机应用系统的基础和核心。数据库技术最初产生于20世纪60年代中期，根据数据模型的发展，可以划分为三个阶段：第一代的网状、层次数据库系统；第二代的关系数据库系统；第三代的以面向对象模型为主要特征的数据库系统。 鉴于数据库的重要性，对其访问的高效和数据库的稳定成了当今非常重要的一个环节，各个不同的系统采取数据库的访问方式很有可能都不一样。面向对象的开发方法是当今的主流，但是同时我们不得不使用关系型数据库，所以在企业级应用开发的环境中，对象、关系的映射（ORM）是一种耗时的工作。大部分企业应用不得不与他们的后端数据库频繁交互。为了让这种交互成为可能，并且使得交互变得有效而迅捷，企业应用开发者在应用和底下的数据库之间创建了一个“持久层” （persistence layer）。1.2 设计意图几乎所有的应用都需要持续性数据。持续性在应用开发中是一个基本的概念，比如如果当主机停电时一个信息系统没有保存用户输入的数据，这样的系统几乎没有实际的用途。这个数据库负责存储从应用到数据库的数据，也负责数据的检索、更新和删除。在基于J2EE的企业应用中，组成这个持久层的Java类既可以映射对象到数据，也可以映射数据到对象。 Hibernate 是一个开源对象/与持久性和查询相关的框架。这种新的ORM映射工具，它不仅提供了从Java类到数据表之间的映射，也提供了数据查询和恢复机制。相对于使用JDBC和SQL来手工操作数据库，使用Hibernate，可以大大减少操作数据库的工作量。Hibernate 是一个ODMG3 interface ，只要有Lesser GNU Public License (LGPL)就可以从 处免费下载。ODMG3 是由对象数据管理小组（ODMG）开发的规范，ODMG 是一个由不同的投资商和兴趣小组为开发用于对象数据库和对象相关的映射产品的可移植性规范而结成的联盟。该规范推动了在不止一个产品上运行的可移植应用程序的开发。它既是开源的和免费的，使得用户在需要的时候可以修改源代码，进行功能的定制，它又是轻量级封装，避免引入过多的复杂问题，调试容易，也减轻程序员的负担，另外它还具有良好的可扩展性，API开放，当本身功能不够的时候，可以自己进行编码扩展所需的功能。1.3 设计概述 建立一个持久层是简单的，只要在Java对象和相应的数据库之间存在线性关系（例如：一个对象域映射到相应的数据库表格的某一列）。但是这种关系常常难于建立，因为对象或者下层的数据库结构复杂（例如，对象具有混合的类型、集合、和属性；数据库表格有外部钥匙约束、串联属性）。经常，在开发持久层的时候，后端数据库的属性和它的模式假设永远保持不变。基于这种假设，所有的持久性操作在应用中是硬编码的，因此只能绑定到一种特殊的数据库模式中。当后端的数据库模式任何时候发生改变（这在现实生活中经常发生），这种方法极耗时间和精力。数据库模式的改变导致了整个持久层必须重写，应用程序代码本身也有可能要进行大量的修改。这是一个单调乏味、非常费时的任务。 本设计采用的是Spring的框架配置加上Hibernate的解决方案，就是由Hibernate负责底层的数据持久层，但是不使用Hibernate自带的配置文件，而是使用Spring框架下的配置，让Spring框架和Hibernate进行一个整合，以吸取二者之长，在效率和简便性上面达到最佳组合。1.4 论文组织本次设计的论文大致分为4个章节：第一个章节是引言部分，总体介绍了课题背景，设计意图，设计概述；第二个章节是阐述概念，本章节对ORM，Spring和Hibernate的概念作了一个较为详细的介绍，让未曾接触过这些方面的读者能有个比较清晰的认识，再对现有持久层技术作一个对比，让读者明白为什么会选择Hibernate而不是JDO或者别的解决方案；第三个章节设计方案和具体实现过程，到这部分实现一个从理论到实践的转换，在实践的角度上把整个设计过程进行一个较为条理的综合，让读者明白上文所述的各项技术如何运用到项目中去； 第四个章节是最后的总结语，对上述阐述进行一个最终的总结，指出还存在的问题以及努力的方向。第二章 基础概念 由于本次设计使用到的技术在实际应用领域上还算是比较新颖，在本章就重点对设计中使用到的各种技术，以及技术牵涉到的概念进行比较全面的介绍。2.1 ORM2.1.1 ORM概念 上文提到的ORM映射是本设计的核心理论，ORM是Object/Relation Mapping的缩写，翻译过来就是对象/关系映射，字母O起源于对象(Object),而R则来自于关系(Relational)。几乎所有的程序里面，都存在对象和关系数据库。在业务逻辑层和用户界面层中，我们是面向对象的。当对象信息发生变化的时候，我们需要把对象的信息保存在关系数据库中。 当你开发一个应用程序的时候(不使用O/R Mapping),你可能会写不少数据访问层的代码，用来从数据库保存，删除，读取对象信息，等等。你在DAL中写了很多的方法来读取对象数据，改变状态对象等等任务。而这些代码写起来总是重复的。如果看看DAL代码，你肯定会看到很多近似的通用的模式。我们以保存对象的方法为例，你传入一个对象，为SqlCommand对象添加SqlParameter，把所有属性和对象对应，设置SqlCommand的CommandText属性为存储过程，然后运行SqlCommand。对于每个对象都要重复的写这些代码。除此之外，还有更好的办法就是采用ORM，使用ORM可以大大降低学习和开发成本，现代技术的发展，使得我们不得不不停地学习。2.1.2 ORM的好处我们不仅要学习面向对象、UML、设计模式等知识，而且还需要学习Sql Server、ADO.NET、DataSet、DataReader等知识。而在实际的开发中，真正对客户有价值的是其独特的业务功能，而现在的现状是我们花费了大量的时间在编写数据访问，CRUD方法，包括后期的Bug查找，维护等也会花费相当多的时间在数据处理上。这就是说，我们在实际的开发中很多的时间都被浪费在根本不创造价值的非业务事件上了。在使用ORM之后，我们将不需要再浪费太多的时间在ADO.NET和Sql语句上。ORM框架已经把数据库转变成了我们熟悉的对象，我们将只需要了解面向对象开发就可以实现数据库应用程序的开发。通过建立ORM系统，能够大量减少程序开发代码，实现ORM后，开发数据层就比较简单，大大减少了出错机会。同时通过Cache的实现，能够对性能进行调优，实现了ORM区隔了实际数据存储和业务层之间的关系，能够对每一层进行单独跟踪，增加了性能优化的可能。利用ORM可以将业务层与数据存储隔开，开发人员不需要关系实际存储的方式，如果我们需要把SQL Server数据库换成ORACLE数据库，只需要修改配置文件就可，不需要修改程序。2.2 Hibernate2.2.1 JDBC和HibernateJDBC可以说是访问持久数据层最原始、最直接的方法。JDBC是Java的开发者Sun的Javasoft公司制定的Java数据库连接(Java Data Base Connectivity)技术的简称，是为各种常用数据库提供无缝联接的技术。JDBC向应用程序开发者提供了独立于数据库的统一的API。这个API提供了编写的标准和考虑所有不同应用程序设计的标准。其奥秘是一组由驱动程序实现的Java接口。驱动程序负责标准JDBC调用向支持的数据库所要的具体调用转变。除了向开发者提供统一的独立于DBMS的框架外，JDBC还提供了让开发者保持数据库厂家提供的特定功能的办法。JDBC驱动程序必须支持ANSI AQL-2项目层，但JDBC允许开发者直接将查询字符串传递到连接的驱动程序。这些字段可能是ANSI SQL也可能不是，或者根本不是AQL。这些字符串的使用是基础驱动程序的事。之前通过Java访问数据库的唯一方法就是利用Java中的流调和访问Common Gateway Interface（CGI，公用网关接口）程序。通过Java调用CGI脚本其实是执行一个访问数据库并返回结果的独立程序。但是使用这种方法速度很慢，而且会在应用程序中引入更多的错误。这是由于利用两种不同的开发语言开发程序，需要掌握两种不同的技术。使用JDBC，用户只要了解Java语言即可，而使用CGI，用户必须同时使用Java和另一种编程语言。使用JDBC的另一个原因是它的速度比CGI方法更快。使用CGI方法通常要求计算机执行另一个独立的程序。这个独立的程序访问数据库，处理数据，并将结果返回给调用程序。这就需要多级处理，因而增加了等待时间和出错概率。在企业级应用开发中，我们可能使用DAO（Data Access Object）模式来把数据访问封装起来，然后在其它的层中同一调用。这种方式的优点是运行效率最高，但JDBC+DAO也存在很多的问题，因为很难做到把关系表记录完整的映射到持久对象的关系上来，这主要体现在多表的关系无法直接映射到对持久对象的映射上来，可能是一个表映射多个持久对象，有可能是多个表映射一个持久对象，更有可能的是表的某些字段映射到一个持久对象，但是另外一些字段映射到别的持久对象上。而且即使这些问题都处理好了，也不能直接按照对象的方式来对持久对象（PO）编程，因为存在1：N关系的持久对象的查询其实就是1+n次对数据库的SQL，这样将会造成访问的效率极其低下，最后可能导致不得不整个修改底层设计，最后等于是完全抛弃了对象设计，完全是按照表字段进行操作，又回到了按照过程进行编程的老路上来。 在这种情况下就需要一个实用的ORM工具，现在市面上有几种ORM工具可供选择，比如JDO，但是由于一些原因，诸如：1. 不是开源免费的工具，这点在企业开发当中是非常重要的，大家都知道许多好产品都会商业化，成为商业产品，而很多又是国外的产品，在国内根本就没有销售和技术的支持。这就决定了某些产品只能研究学习之用，而不能在实际用途中大显身手，否则的话，你把软件卖给客户的时候，你还要告诉他另外去购买另外一个别的在国内没有支持的产品，如果那个软件出了什么问题，很遗憾，我们没有办法帮您解决，我们只能解决我们份内的事情，这样的答复无论如何客户是肯定没有办法接受的。2. 不是轻量级封装，这点将很明显的影响到日后的调试和维护工作，因为封装的太多，一旦出现了错误，你很难定位那个错误是出现在什么地方，封装的越轻，越能容易的找到问题的出处，越容易解决。3. 有些产品的标准很不完善，比如上文提到的JDO，它的JDOQL（由JDO自定义的数据库语句，类似SQL语句，但并不完全一样）不够完善，影射关系的表达不够强大，另外就是各个标准之间的产品分裂，由于JDO1.0标准的缺陷，而JDO2.0标准还遥遥无期，而各个JDO厂商为了能够在竞争中脱颖而出，那么除了在易操作性和性能上的提高之外，想要吸引客户，就必须有自己的产品特色。那么1.0标准的缺陷正好给了他们发挥的舞台，每个厂商都会有自己独到的解决方案来解决标准的缺陷，然而这却造成了JDO 产品事实上的分裂，可能很多人都会觉得这样的百花齐放很不错，但是实际上呢，你写好的POJO，用一种JDO的Enhancer进行Enhance过以后得到的 PO，在另一个JDO产品上跑不起来。这很像当年Unix的分裂，结果就是二进制代码级的不兼容，而只能在C源代码级兼容。现在的JDO也有这样的趋势，就像服务器软件的差别一样，一个在Weblogic上开发好的EJB，移植到Websphere，你一定需要重新进行配置。在这样的环境下，Hibernate的出现正好填补了这个空缺。2.2.2 新技术Hibernate 正如上面所说的ORM，Hibernate正是基于ORM理论的核心框架，使用Hibernate你不用每次再去考虑如何连接数据库，如何用各种SQL语句对数据库进行操作，如何对数据库里面的数据进行同步，这个时候的数据库对于编程人员来说就是一个对象，你可以对对象作任何你想要的操作，而不需要记住那些繁琐的语句。 Hibernate 帮助基于普通的Java对象模型的持久对象的创建，从而允许持久对象拥有复杂的结构如混合类型、集合和属性，还可以拥有用户自定义的类型。现在这些持久对象可以有效的反映出底层数据库模式的复杂结构。2.2.3 Hibernate特性Hibernate 依赖于“运行期反射”。“运行期反射”在运行期收集关于对象和它们相应的数据库映射的信息，这就废除了持久层内对象数据库映射的硬编码。这样，Hibernate使得持久层以持久层代码的最小修改就能够适应底层数据库模式的任何未知变化。反射是核心Java的一个特征，它促使Java代码发现关于所装载的类的域、方法和构造器。反射允许使用反射的域、方法和构造器，在安全限制内，运行对象上的底层配对物。 Hibernate 自动将持久层扩展到更大的范围，使用它内建的设备CodeGenerator 和 SchemaExport 就可以完成，从而大大的降低了硬编码的故障率。Hibernate 也提供了易于使用的Hibernate Query Language (HQL)，它是作为“到SQL的最小化面向对象扩展”而设计的一种丰富的查询语言。HQL 推动了数据库类型独立查询的编写，数据库类型独立查询在运行期内可以转换成底层数据库的本地SQL方言。该方法保证了底层数据库类型改变时（如从Oracle 变为PostgreSQL ）代码中查询不受影响。 为了提高效率，Hibernate包括了一些策略，如与数据库交互时的多重最优化，包括对象的缓存、有效外部连接的获取、必要时SQL语句的执行。Hibernate的过程开销比JDBC少10%。2.3 Spring框架2.3.1 Spring特性 Spring是一个很大的框架，可以说也是一个容器，它的出现让J2EE更容易使用，也能让开发者培养一种良好的编程规范。SpringFramework 实际上是Expert One-on-One J2EE Design and Development 一书中所阐述的设计思想的具体实现。在One-on-One 一书中，作者Rod Johnson 倡导J2EE 实用主义的设计思想，并随书提供了一个初步的开发框架实现（interface21 开发包）。而SpringFramework 正是这一思想的更全面和具体的体现。Rod Johnson 在interface21 开发包的基础之上，进行了进一步的改造和扩充，使其发展为一个更加开放、清晰、全面、高效的开发框架。Spring的一个特性就是能让它框架内的组件看起来更像“组件”，为什么这么说呢，首先，我们的组件并不需要实现框架指定的接口，因此可以轻松的将组件从Spring中脱离，甚至不需要任何修改（这在基于EJB框架实现的应用中是难以想象的）。其次，组件间的依赖关系减少，极大改善了代码的可重用性。Spring的依赖注入机制，可以在运行期为组件配置所需资源，而无需在编写组件代码时就加以指定，从而在相当程度上降低了组件之间的耦合，实现了组件真正意义上的即插即用。这正是Spring最具价值的特性之一。诚然，即使没有Spring，实现面向接口的设计也不困难。Spring对于面向接口设计的意义，在于它为面向接口编程提供了一个更加自然的平台。基于Spring开发，程序员会自然而然倾向于使用接口来定义不同层次之间的关联关系，这种自发的倾向性，来自于Spring所提供的简单舒适的依赖注入实现。Spring使得接口的定义和使用不再像传统编码过程中那么繁琐（传统编码过程中，引入一个接口，往往也意味着同时要引入一个Factory类，也许还有一个额外的配置文件及其读写代码）。这样各个组件的测试也变得更为简单，也能更简单的在组件中添加模块。站在应用开发的实际角度来说，其最大的优势在于：Spring是一个从实际项目开发经验中抽取的，可高度重用的应用框架。Spring涵盖了应用系统开发所涉及的大多数技术范畴，包括MVC、ORM以及Remote Interface等，这些技术往往贯穿了大多数应用系统的开发过程。Spring从开发者的角度对这些技术内容进行了进一步的封装和抽象，使得应用开发更为简便。Spring并非一个强制性框架，它不仅提供了很多独立的组件可供选择，还能自己添加别的组件，Spring能让它们一起工作的很好。2.3.2 Spring中的IOCSpring Framework中目前最引人注目的，也就是名为控制反转（IOC Inverse Of Control）或者依赖注入（DI Dependence Injection）的设计思想，这是相当优秀的设计理念。IOC，用白话来讲，就是由容器控制程序之间的关系，而非传统实现中，由程序代码直接操控。这也就是所谓“控制反转”的概念所在：控制权由应用代码中转到了外部容器，控制权的转移，是所谓反转。正在业界为IOC争吵不休时，大师级人物Martin Fowler也站出来发话，以一篇经典文章Inversion of Control Containers and the Dependency Injection pattern为IOC正名，至此，IOC又获得了一个新的名字：“依赖注入 （Dependency Injection）”。从名字上理解，所谓依赖注入，即组件之间的依赖关系由容器在运行期决定，形象的来说，即由容器动态的将某种依赖关系注入到组件之中。在这里举一个简单的例子，IBM T40笔记本电脑一台、USB硬盘和U盘各一只，想必大家对这些东西都是比较熟悉的了。这三个设备都有一个共同点，都支持USB 接口。当我们需要将数据复制到外围存储设备时，可以根据情况，选择是保存在U盘还是USB硬盘，下面的操作大家也都轻车熟路，无非接通USB接口，然后在资源浏览器中将选定的文件拖放到指定的盘符。这样的操作在过去几年中每天都在我们身边发生，而这也正是所谓依赖注入的一个典型案例。再看这个例子中，笔记本电脑与外围存储设备通过预先指定的一个接口（USB）相连，对于笔记本而言，只是将用户指定的数据发送到USB接口，而这些数据何去何从，则由当前接入的USB设备决定。在USB设备加载之前，笔记本不可能预料用户将在USB接口上接入何种设备，只有USB设备接入之后，这种设备之间的依赖关系才开始形成。对应上面关于依赖注入机制的描述，在运行时（系统开机，USB 设备加载）由容器（运行在笔记本中的Windows操作系统）将依赖关系（笔记本依赖USB设备进行数据存取）注入到组件中（Windows文件访问组件）。这就是依赖注入模式在现实世界中的一个版本。对比传统的实现方式（如通过编码初始化DataSource实例），我们可以看到，基于依赖注入的系统实现相当灵活简洁。通过依赖注入机制，我们只需要通过简单的配置，而无需任何代码就可指定实例，完成自身的业务逻辑。 2.4 本章小结 本章对本次设计所用到的关键技术能进行了比较详细的介绍，在下一个章节，我们将开始利用这两个核心技术实现本次设计。第三章 设计方案和实现 上文已经对一些必要的基础知识进行了较为全面的介绍，本章节是本次设计的实践部分，从设计方案开始到具体的实现，都将进行一个比较条理的描述。3.1 设计方案概述 本次设计是建行的原型机系统，目的是为了考察Hibernate的实际运行状况，从效率和简易性来决定在之后的系统里面是否采用Hibernate来作为开发持久层的工具。 这套原型机系统使用了Spring作为总体框架，在Spring的基础上使用Hibernate作为持久层开发的工具，由Hibernate负责和底层的数据库进行交互，由于设计只是原型机系统，所以执行的功能比较简单，具有添加用户，用户权限，列出用户清单，修改用户信息，删除用户信息，页面跳转功能。 具体的流程是由负责显示的JSP页面调用UCC层的方法，UCC层不作处理只是负责继续把调用命令传递到事务层（Biz/service），在这一层上也不作处理，继续调用下一层，也就是最后的数据持久层，由这一层来和数据库进行一切交互，读取和写入，然后把这些数据层层上递，返回到前端显示JSP页面，经过中间两个UCC层和事务层是由框架决定的。 首先我们对这次设计所使用的开发IDE作一个简单的介绍。3.2 IDE开发工具 本次设计主要使用的工具是Eclipse，Eclipse是一个开放可扩展的集成开发环境(IDE)。IBM公司是花了多年的时间才开发出基于 Java的公开源代码软件Eclipse，并在其中投资了4000万美元，Eclipse软件可以用于管理多种开发任务，包括测试、性能调整及程序调试等，而且还可以集成来自多个供货商的第三方应用程序开发工具。此外，Eclipse软件非常适合开发电子商务应用程序，例如IBM公司自己的面向Web服务的WebSphere应用程序开发工具就是建立在 Eclipse基础之上的。除此之外，Eclipse平台是一个成熟的、精心设计的及可扩展的体系结构。Eclipse的价值还在于它为创建可扩展的集成开发环境提供了一个开放源码平台。这个平台允许任何人构建与环境和其他工具无缝集成的工具，而工具与Eclipse无缝集成的关键便是插件。它还是开放源代码的项目，并可以免费下载，IBM官方提供的版本只有最基本的功能，也只能支持为数并不很多的格式，甚至连非常热门的XML文件它都不能直接支持编辑，但正因为Eclipse的开放性和扩展性，使得广大的爱好者在原先的基础上扩展了非常多的功能，提供了最大的支持性和兼容性，这恐怕才是IBM当初开发Eclipse的初衷，这种方式有点类似于当年的Linux，由linus本人创建了linux的核心，但是后来的普及和流行却脱离不了广大爱好者的支持。Eclipse对于开发者非常实用的一个功能就是它里面的Junit Test组件，通过这个组件，开发者可以很方便的对他们的模块/组件进行比较全面的测试，而不用等到最后的整合完才来做这一步，这样能极大的提高工作效率。下面就是使用Eclipse的实际开发图3.1：图3.1 Eclipse开发图 下面就将对Hibernate开发以及它和Spring框架的整合进行一个介绍。3.3 构建持久层对象 Hibernate的安装非常简单，或者可以说不需要安装，只需要从SourceForge下载一个压缩包，本次设计使用的是最新版本的Hibernate 3，然后把Hibernate提供的hibernate3.jar和一些第三方的运行库拷贝到WEB-INFlib目录下，这些第三方的运行库包含在下载的Hibernate lib目录下。定位用于将要使用的数据库（如用于Oracle的Ojdbc14.zip）的JDBC 驱动，添加他的路径到全局类路径。现在，Hibernate已经为开发给定应用的持久层做好准备。 从这里开始构建Hibernate的基础代码POJO，POJO 在Hibernate 语义中理解为数据库表所对应的Domain Object。这里的POJO就是所谓的“Plain Ordinary Java Object”，字面上来讲就是无格式普通Java 对象，简单的可以理解为一个不包含逻辑代码的值对象（Value Object 简称VO），也称为一个持久对象，POJO在这里体现的就是ORM中Object层的语义，而映射（Mapping）文件则是将对象（Object）与关系型数据（Relational）相关联的纽带。下面就是一个具体的POJO：AppUser.java，对应的是本次设计的用户表：public class AppUser /*属性，和BranchUser表中的字段对应*/ private Long userid; private String name; private String password; private Long status; /*和其它类之间的映射关系*/ private Set roles; private Branch branch; /*属性的访问方法,必须是公共的方法*/ /*/ * hibernate.id unsaved-value=null generator-class=native/ * return/ */public void setUserid(Long userid)this.userid = userid;public Long getUserid()return userid;public void setName(String name)=name;/* * * return */public String getName()return ;public void setPassword(String password)this.password = password;public String getPassword()return this.password;public void setStatus(Long sta)this.status = sta;public Long getStatus()return status;/*操作和其它对象之间的关系*/public void setRoles(Set roles)this.roles=roles;public Set getRoles()return this.roles;public void setBranch(Branch branch)this.branch = branch;public Branch getBranch()return this.branch; 其中userid，name，password和status都是表user里面的属性，和表里面的字段是一一对应的，并且类型一致。而其setuserid和getuserid方法其实就是Hibernate当中和数据库交互的方式，setxxx方法代表设置值，也就是把userid设置成什么数值，getxxx方法代表读取值，这样的数据库交互方式和面对对象编程几乎是一模一样，使开发者不用多花时间在数据库语句上，而且看起来显得非常简洁明了。3.4 映射描述 这样就开发好了一个持久层对象，接下去的任务就是书写对象、关系映射描述。这个描述使用XML文件来实现，通常以*.hbm.xml作为后缀。构建这个映射文件有3个方法：1.手工编写2. 直接从数据库中导出表结构，并生成对应的ORM文件和Java 代码。这是实际开发中最常用的方式，也是这里所推荐的方式。通过直接从目标数据库中导出数据结构，最小化了手工编码和调整的可能性，从而最大程度上保证了ORM文件和Java 代码与实际数据库结构相一致。3. 根据现有的Java 代码生成对应的映射文件，将Java 代码与数据库表相绑定。通过预先编写好的POJO 生成映射文件，这种方式在实际开发中也经常使用，特别是结合了xdoclet 之后显得尤为灵活，其潜在问题就是与实际数据库结构之间可能出现的同步上的障碍，由于需要手工调整代码，往往调整的过程中由于手工操作的疏漏，导致最后生成的配置文件错误，这点需要在开发中特别注意。虽然Hibernate官方有提供MiddleGen for Hibernate 和Hibernate_Extension工具包，我们可以很方便的根据现有数据库，导出数据库表结构，生成ORM和POJO。我们也可以使用Eclipse的Hibernate插件来自动生成映射文件。如图3.2：图3.2 Eclipse的Hibernate插件以下就是对应上述AppUser.java的映射文件User.hbm.xml： 3.5 Hibernate语义 在User.hbm.xml映射文件中，指定了要映射的类和映射的表，并且指定了表的各个字段和Java对象AppUser中各个字段的映射关系，比如AppUser对象中的userid属性对应了Branchuser表的userid字段，其中userid是primary key。上面many-to-many和many-to-one字段分别对应了Role和Branch表的多对多和多对一关系，使用userid和两个表的Roleid和BranchId关联。dynamic-update字段代表了生成Update SQL时，仅包含发生变动的字段，其默认值是“false”; dynamic-insert字段代表了生成Insert SQL时，仅包含非空(null)字段，其默认值是“false”。generator class字段代表了主键的产生方式，increment的意思是主键按数值顺序递增。此方式的实现机制为在当前应用实例中维持一个变量，以保存着当前的最大值，之后每次需要生成主键的时候将此值加1作为主键。但是这种方式可能产生的问题是：如果当前有多个实例访问同一个数据库，那么由于各个实例各自维护主键状态，不同实例可能生成同样的主键，从而造成主键重复异常。因此，如果同一数据库有多个实例访问，此方式必须避免使用。set字段里的lazy代表的是否采用延迟加载，为了避免一些情况下，关联关系所带来的无谓的性能开销。Hibernate引入了延迟加载的概念。比如，user对象在加载的时候，可能会同时读取其所关联的多个地址（address）对象（虽然本例子中没有address的属性），对于需要对address进行操作的应用逻辑而言，关联数据的自动加载机制的确非常有效。但是，如果我们只是想要获得user的用户名（姓名）属性，而不关心user的地址（address）信息，那么自动加载address的特性就显得多余，并且造成了极大的性能浪费。为了获得user的用户名属性，我们可能还要同时从数据库中读取数条无用的地址数据，这导致了大量无谓的系统开销。而延迟加载特性的出现，正是为了解决这个问题。所谓延迟加载，就是在需要数据的时候，才真正执行数据加载操作。对于user对象的加载过程，也就意味着，加载user对象时只针对其本身的属性，而当我们需要获取user对象所关联的address信息时（如执行user.getAddresses时），才真正从数据库中加载address数据并返回；inverse字段代表的是用于标识双向关联中的被动方一端。inverse=false的一方（主控方）负责维护关联关系。默认值是“false”。cascade字段代表操作级联（cascade）关系。其可选值：all : 所有情况下均进行级联操作，none：所有情况下均不进行级联操作，save-update:在执行save-update时进行级联操作，delete：在执行delete时进行级联操作。Inverse，直译为“反转”。在Hibernate语义中，Inverse指定了关联关系中的方向。关联关系中，inverse=“false”的为主动方，由主动方负责维护关联关系。而Cascade，译为“级联”，表明对象的级联关系，如TUser的Cascade设为all，就表明如果发生对user对象的操作，需要对user所关联的对象也进行同样的操作。如对user对象执行save操作，则必须对user对象相关联的address也执行save操作。开发者常常混淆inverse和cascade，实际上，这是两个互不相关的概念。Inverse指的是关联关系的控制方向，而cascade指的是层级之间的连锁操作。sort字段则是代表了排序类型，其可选值：unsorted ：不排序（默认），natural ：自然顺序（避免与order-by搭配使用），comparatorClass ：指以某个实现了java.util.Comparator接口的类作为排序算法；outer-join字段代表了是否使用外联接。true：总是使用outer-join，false：不使用outer-join，auto(默认) ：如果关联对象没有采用Proxy机制，则使用outer-join。其余持久层对象和映射文件基本上类似上面，就不再叙述。 到此为止我们已经构建了hibernate所需要的大部分内容，所剩下的就是进行一些配置，然后就可以使用hibernate对数