JPA 和 ORM 概念

本文介绍了Java Persistence API (JPA)及其在企业级应用中的优势,对比了不同JPA供应商的特点,并探讨了对象关系映射(ORM)的概念及其实现方式。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

     一、JPA     Java Persistence Api    JPA通过JDK5.0或XML描述对象--数据库关系表之间的映射关系,并将运行期的实体对象持久化到数据库中。

 二、JPAEJB 3.0软件专家组开发,作为JSR-220实现的一部分。

    JPA的总体思想和现有HibernateTopLinkJDOORM框架大体一致。总的来说,JPA包括以下3方面的技术:
  ORM映射元数据,JPA支持XMLJDK 5.0注解两种元数据的形式,元数据描述对象和表之间的映射关系,框架据此将实体对象持久化到数据库表中;
  JPA API,用来操作实体对象,执行CRUD操作,框架在后台替我们完成所有的事情,开发者从繁琐的JDBCSQL代码中解脱出来。
  查询语言,这是持久化操作中很重要的一个方面,通过面向对象而非面向数据库的查询语言查询数据,避免程序的SQL语句紧密耦合。

三、JPA的优势
  1 标准化
  JPA JCP 组织发布的 Java EE 标准之一,因此任何声称符合 JPA 标准的框架都遵循同样的架构,提供相同的访问 API,这保证了基于JPA开发的企业应用能够经过少量的修改就能够在不同的JPA框架下运行。
  2 对容器级特性的支持
  JPA 框架中支持大数据集、事务、并发等容器级事务,这使得 JPA 超越了简单持久化框架的局限,在企业应用发挥更大的作用。
  3 简单易用,集成方便
  JPA的主要目标之一就是提供更加简单的编程模型:在JPA框架下创建实体和创建Java 类一样简单,没有任何的约束和限制,只需要使用 javax.persistence.Entity进行注释;JPA的框架和接口也都非常简单,没有太多特别的规则和设计模式的要求,开发者可以很容易的掌握。JPA基于非侵入式原则设计,因此可以很容易的和其它框架或者容器集成。
  4 可媲美JDBC的查询能力
  JPA的查询语言是面向对象而非面向数据库的,它以面向对象的自然语法构造查询语句,可以看成是Hibernate HQL的等价物。JPA定义了独特的JPQLJava Persistence Query Language),JPQLEJB QL的一种扩展,它是针对实体的一种查询语言,操作对象是实体,而不是关系数据库的表,而且能够支持批量更新和修改、JOINGROUP BYHAVING 等通常只有 SQL 才能够提供的高级查询特性,甚至还能够支持子查询。
  5 支持面向对象的高级特性
  JPA 中能够支持面向对象的高级特性,如类之间的继承、多态和类之间的复杂关系,这样的支持能够让开发者最大限度的使用面向对象的模型设计企业应用,而不需要自行处理这些特性在关系数据库的持久化。
  四、JPA的供应商
  JPA 的目标之一是制定一个可以由很多供应商实现的API,并且开发人员可以编码来实现该API,而不是使用私有供应商特有的API。因此开发人员只需使用供应商特有的API来获得JPA规范没有解决但应用程序中需要的功能。尽可能地使用JPA API,但是当需要供应商公开但是规范中没有提供的功能时,则使用供应商特有的API
  1 Hibernate
  JPA是需要Provider来实现其功能的,Hibernate就是JPA Provider中很强的一个,目前来说应该无人能出其右。从功能上来说,JPA现在就是Hibernate功能的一个子集。Hibernate 3.2开始,就开始兼容JPAHibernate3.2获得了Sun TCKJPA(Java Persistence API) 兼容认证。
  只要熟悉Hibernate或者其他ORM框架,在使用JPA时会发现其实非常容易上手。例如实体对象的状态,在Hibernate有自由、持久、游离三种,JPA里有newmanageddetachedremoved,明眼人一看就知道,这些状态都是一一对应的。再如flush方法,都是对应的,而其他的再如说Query query = manager.createQuery(sql),它在Hibernate里写法上是session,而在JPA中变成了manager,所以从HibernateJPA的代价应该是非常小的
  同样,JDO,也开始兼容JPA。在ORM的领域中,看来JPA已经是王道,规范就是规范。在各大厂商的支持下,JPA的使用开始变得广泛。
  2 Spring
  Spring + Hibernate 常常被称为 Java Web 应用人气最旺的框架组合。而在 JCP 通过的 Web Beans JSR ,却欲将JSF + EJB + JPA 、来自 JBoss SeamSpring 除外)的一些组件和EJB 3(目前能够提供有基本拦截和依赖注入功能的简化 Session Bean 框架)的一个 Web 组合进行标准化。如今的 Spring 2.0 JPA 提供了完整的 EJB 容器契约,允许 JPA在任何环境内可以在 Spring 管理的服务层使用(包括 Spring 的所有 AOP DI 增强)。同时,关于下一个Web应用组合会是 EJBSpring + Hibernate 还是 Spring + JPA 的论战,早已充斥于耳。
  在Spring 2.0.1中,正式提供对JPA的支持,这也促成了JPA的发展,要知道JPA的好处在于可以分离于容器运行,变得更加的简洁。
  3 OpenJPA
  OpenJPA Apache 组织提供的开源项目,它实现了 EJB 3.0 中的 JPA 标准,为开发者提供功能强大、使用简单的持久化数据管理框架。OpenJPA 封装了和关系型数据库交互的操作,让开发者把注意力集中在编写业务逻辑上。OpenJPA 可以作为独立的持久层框架发挥作用,也可以轻松的与其它 Java EE 应用框架或者符合 EJB 3.0 标准的容器集成。
  4 其它
  目前支持的实现包括ToplinkHibernate Entitymanager等。TopLink以前需要收费,如今开源了。OpenJPA虽然免费,但功能、性能、普及性等方面更加需要加大力度。
  对于EJB来说,实体Bean一直是被批评的对象,由于其太复杂和庞大。JPA的出现,很大程度的分离了复杂性。这让EJB的推广也变得容易。
  总而言之,JPA规范主要关注的仅是API的行为方面,而由各种实现完成大多数性能有关的调优。尽管如此,所有可靠的实现都应该拥有某种数据缓存,以作为选择。但愿不久的将来,JPA能成为真正的标准。
  五、小结
  EJB 3.0JPA 毫无疑问将是Java EE 5的主要卖点。在某些领域中,它们给Java社区带来了竞争优势,并使Java 在其他领域与竞争对手不分伯仲(因为,不可否认,目前某些领域尚不存在基于标准的方法)。
  过去数年来,Spring Framework一直是EJB在企业领域的主要竞争对手。EJB3.0规范解决了很多促进Spring兴起的问题。随着它的出现,EJB3.0毫无疑问比Spring提供了更好的开发体验——最引人注目的优势是它不需要配置文件。
  JPA提供一种标准的OR映射解决方案,该解决方案完全集成到EJB30兼容的容器中。JPA的前辈将会继续稳定发展,但是业务应用程序中的 raw 使用将可能会减少。实现 JPA 兼容的实体管理器似乎很可能是此类技术的发展方向。
  Java EE系列规范的较大问题与JPA没有任何关系。Java EE 系列规范的问题涉及到 WebEJB容器之间的集成。Spring在此领域仍然具有主要竞争优势。JBossSeam项目尝试使用自定义的方法来解决这一问题。Caucho Resin应用服务器试图扩展容器边界并支持在Web容器中使用@EJB注释。我们希望Java EE 5.1将解决层集成的问题,为我们提供一个全面而标准的依赖性注入方法。
  在不久的将来,Sun可能会将JPA作为一个单独的JSR对待,同时JPA还可能作为Java SE的一部分。不过这些都不太重要,重要的是,我们现在已经可以在脱离容器的情况下、在Java SE应用中使用JPA了。
  JPA已经作为一项对象持久化的标准,不但可以获得Java EE应用服务器的支持,还可以直接在Java SE中使用。开发者将无需在现有多种ORM框架中艰难地选择,按照Sun的预想,现有ORM框架头顶的光环将渐渐暗淡,不再具有以往的吸引力。

ORM是什么?
 

     对象关系映射Object Relational Mapping,简称ORM)是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术。 简单的说,ORM是通过使用描述对象和数据库之间映射的元数据,将java程序中的对象自动持久化到关系数据库中。本质上就是将数据从一种形式转换到另外一种形式。 这也同时暗示者额外的执行开销;然而,如果ORM作为一种中间件实现,则会有很多机会做优化,而这些在手写的持久层并不存在。 更重要的是用于控制转换的元数据需要提供和管理;但是同样,这些花费要比维护手写的方案要少;而且就算是遵守ODMG规范的对象数据库依然需要级别的元数据。

      对象-关系映射Object/Relation Mapping,简称ORM),是随着面向对象的软件开发方法发展而产生的。面向对象的开发方法是当今企业级应用开发环境中的主流开发方法,关系数据库是企业级应用环境中永久存放数据的主流数据存储系统。对象和关系数据是业务实体的两种表现形式,业务实体在内存中表现为对象,在数据库中表现为关系数据。内存中的对象之间存在关联和继承关系,而在数据库中,关系数据无法直接表达多对多关联和继承关系。因此,对象-关系映射(ORM)系统一般以中间件的形式存在,主要实现程序对象到关系数据库数据的映射。

      面向对象是从软件工程基本原则(如耦合、聚合、封装)的基础上发展起来的,而关系数据库则是从数学理论发展而来的,两套理论存在显著的区别。为了解决这个不匹配的现象,对象关系映射技术应运而生。

      让我们从O/R开始。字母O起源于"对象"(Object),而R则来自于"关系"(Relational)。几乎所有的程序里面,都存在对象和关系数据库。在业务逻辑层和用户界面层中,我们是面向对象的。当对象信息发生变化的时候,我们需要把对象的信息保存在关系数据库中。

      当你开发一个应用程序的时候(不使用O/R Mapping),你可能会写不少数据访问层的代码,用来从数据库保存,删除,读取对象信息,等等。你在DAL中写了很多的方法来读取对象数据,改变状态对象等等任务。而这些代码写起来总是重复的。
 
  如果打开你最近的程序,看看DAL代码,你肯定会看到很多近似的通用的模式。我们以保存对象的方法为例,你传入一个对象,为SqlCommand对象添加SqlParameter,把所有属性和对象对应,设置SqlCommand的CommandText属性为存储过程,然后运行SqlCommand。对于每个对象都要重复的写这些代码。

  除此之外,还有更好的办法吗?有,引入一个O/R Mapping。实质上,一个O/R Mapping会为你生成DAL。与其自己写DAL代码,不如用O/R Mapping。你用O/R Mapping保存,删除,读取对象,O/R Mapping负责生成SQL,你只需要关心对象就好。

      对象关系映射成功运用在不同的面向对象持久层产品中,如:Torque,OJB,Hibernate,TopLink,Castor JDO, TJDO 等。

      一般的ORM包括以下四部分:
      一个对持久类对象进行CRUD操作的API
      一个语言或API用来规定与类和类属性相关的查询;
      一个规定mapping metadata的工具;
      一种技术可以让ORM的实现同事务对象一起进行dirty checking, lazy association fetching以及其他的优化操作。

一、目前流行的 ORM 产品

      目前众多厂商和开源社区都提供了持久层框架的实现,常见的有:

      Apache OJB (http://db.apache.org/ojb/)
      Cayenne (http://objectstyle.org/cayenne/)
      Jaxor (http://jaxor.sourceforge.net)
      Hibernate (http://www.hibernate.org)
      iBatis (http://www.ibatis.com)
      jRelationalFramework (http://ijf.sourceforge.net)
      mirage (http://itor.cq2.org/en/oss/mirage/toon)
      SMYLE (http://www.drjava.de/smyle)
      TopLink (http://otn.oracle.com/products/ias/toplink/index.html)

      其中 TopLink 是 Oracle 的商业产品,其他均为开源项目。

      其中 Hibernate 的轻量级 ORM 模型逐步确立了在 Java ORM 架构中领导地位,甚至取代复杂而又繁琐的 EJB 模型而成为事实上的 Java ORM 工业标准。而且其中的许多设计均被 J2EE 标准组织吸纳而成为最新 EJB 3.0 规范的标准,这也是开源项目影响工业领域标准的有力见证。

二、对象-关系映射模式

      从《公共仓库元模型:开发指南》一书第8章CWM元仓库中摘录出来的内容,实现了公共仓库元模型(CWM)的UML图到Microsoft SQL Server数据库的映射,是一种将对象层次结构映射成关系型结构的方法。个人认为可以作为将本体(Ontology)文件存储到关系型数据库中的一种可借鉴方法。

      基本情况:公共仓库元模型(CWM)是对象管理组织(OMG)的一种和数据仓库相关的元模型标准,采用UML表示的对象层次结构,在保存到数据库中时由于面向对象的数据库技术的不完善(理论研究和商业应用都不是主流),所以该书的作者倾向于使用成熟的关系型数据库来保存-这也是存储本体时所遇到的问题。

      采用方法:将UML模型中的各种元素通过转换,保存为数据库模式。由于CWM是一种元模型,因此模型的实例也是一种模型,将这种实例以数据库数据的形式保存。使用数据库中比较成熟的存储过程技术提高开发和执行效率。

      1、数据类型映射模式

      1.1简单数据类型模式:建立UML和关系型数据库中简单数据类型的映射表以指导映射。
      1.2枚举数据类型模式:每种枚举类型对应一个表,只有一个列(_EnumLiteral)表示枚举值。
      1.3基于类的数据类型模式:使用外键约束,将基础列与基于类的类型实例相关联。

      2、类映射模型

      每个类对应一个表。单值属性、多值属性、继承关系可以用下述方法映射,而引用属性将在关联映射模式中提到。

      2.1单值属性模式:是cardinality的上界为1的属性,映射到类所对应的表的列上。若其下界也为1(必须有的属性),列属性为NOT NULL。
      2.2多值属性模式:每个多值属性映射成一个独立的表,使用外键连接到类所对应的表上。
      2.3继承模式:每加入一个类的实例时,根据其继承关系自顶向下生成每个类的对象,这些对象具有相同的ID(根对象对应记录的主键)。删除对象实例时,自底向上删除数据。遇到从中间删的情况怎么办?多重继承怎么处理?(金龙飞)

      3、关联映射模式

      3.1一对一关联模式:在关联两端各加一列。
      3.2一对多关联模式:和3.1一样。如果多这端是有序的,还需加入一列表示序号。
      3.3多对多关联模式:将关联单独作一个表。
      3.4组合关联模式:注意级联式删除。
      3.5反演关联模式:关联两端指向相关的类型,和普通关联一样。
      3.6成对关联模式:关联记录两个类间的关系,用交集类表示关联,表示成一个单独的表,每个关联对应一个表,用外键表示它们间的关系。
      3.7关联上的OCL需要分析成对应的存储过程代码。
      3.8保证关联的cardinality也需要分析成对应的存储过程代码。

      4、引用映射模式


      在UML中不存在的MOF特征,指属性是声明为引用类型的实例。用存储过程实现。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值