浅谈对象关系映射（ORM）

 

对象-关系映射是Java应用中的对象到关系数据库中的表的自动的持续化，使用元数据对对象与数据库间的映射进行了描述。本质上，ORM的工作是将数据从一种表示（双向）转换为另一种。这意味着有一些性能损失。然而，如果ORM是作为中间件实现的，就会有许多机会可以进行优化而在手工编码的持续层中这些机会是不存在的。另外一项开销（在开发时）是对控制转换的元数据的准备与管理。而且，这个成本低于维护一个手工编码的解决方案所需的成本。

相比之下，与ODMG兼容的对象数据库甚至需要大量类级别的元数据。

FAQ ORM不是一个Visio插件吗？首字母缩略语ORM也可以指对象角色建模，而且这个术语是在相关的对象-关系映射之前发明的。它描述了一种在数据库建模中使用的信息分析方法，并且主要由微软的Visio（一种图形化建模工具）支持。数据库专家使用它作为更流行的实体-关系建模的替代品或附属品。然而，如果你与Java开发者讨论ORM的话，通常是在对象-关系映射的环境里。

ORM解决方案有以下四部分组成：

■ 在持续类的对象上执行基本的CRUD操作的一组API。

■ 用于指定查询的一种语言或一组API，这些查询会引用类和类属性。

■ 用于指定映射元数据的工具。

■ 实现ORM的一项技术，用来与事务对象交互以完成脏检查、懒关联存取和其它优化功

能。

我们使用ORM这个术语包含所有可以根据元数据的描述自动生成SQL的持续层。我们不包含开发者通过编写SQL和使用JDBC手工解决对象-关系映射问题的持续层。使用ORM，应用与ORMAPI和根据下层SQL/JDBC抽象出来的域模型类进行交互。依赖于这些特征或特定的实现，ORM运行时也可能承担例如乐观锁、缓存等问题的职责，完全免去了应用对这些问题的关心。

让我们看一下可以实现ORM的各种不同的方式。Mark Fussel,一位ORM领域的研究者，定义了ORM品质的四个级别。

纯关系

整个应用，包括用户接口，都是围绕关系模型和基于SQL的关系操作进行设计的。如果低

水平的代码重用是可以容忍的，不考虑它对大型系统的不足，这种方法对于简单的应用不失

为一种优秀的解决方案。直接的SQL可以在每一方面进行微调，但是这些缺点例如缺乏可移植性和可维护性是非常重要的，特别是需要长期运行时。这种类型的应用经常大量地使用存储过程，将业务层的许多工作移动到了数据库中。

轻量对象映射

实体作为类来表示，而类又被手工地映射到关系表。手工编码的SQL/JDBC使用众所周知

的设计模式对业务逻辑进行了隐藏。这种方法非常普遍并且对于那些只有少量实体的应用或

者那些使用普通的元数据-驱动的数据模型的应用来说是很成功的。在这种类型的应用中存储过程也可能有一席之地。

中等对象映射

这种应用是围绕对象模型设计的。SQL在编译时使用代码生成工具生成，或者在运行时由

框架代码生成。对象间的关联由持续性机制支持，并且查询可能使用面向对象的表达式语言

指定。对象被持续层缓存。很多的ORM产品和自制的持续层都至少支持这一级别的功能。它非常适合包含一些复杂事务的中等规模的应用，特别是当不同的数据库产品间的移植性非常重要时。这些应用通常不使用存储过程。

完全对象映射

完全的对象映射支持复杂的对象模型：组合、继承、多态和“可达的持续性”。持续层实

现了透明的持续性；持续类不必继承任何特定的基类或实现任何特定的接口。高效的存取策

略（懒惰和即时存取）和缓存策略都对应用透明地实现了。这一级别的功能很难由自制的持

续层达到——它相当于数月或数年的开发时间。