什么是ORM

最新推荐文章于 2022-07-03 14:46:49 发布

lionzl

最新推荐文章于 2022-07-03 14:46:49 发布

阅读量1.2k

点赞数

文章标签： orm hibernate 数据库 microsoft delphi dataset

对象关系映射（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特征，指属性是声明为引用类型的实例。用存储过程实现。

只有企业级项目才特别需要使用ORM

刚看了一篇文章，本来想跟个贴追捧一下ORM，最后还是决定单独写一个Post，以充分发挥“对台戏”的效果。

先说明一点，我其实不喜欢ORM这个概念，我觉得这个概念并不十分优雅，尽管非常普遍。

什么是大型软件
我不知道原文中的大型软件是什么概念。不过我心目中的概念是结构、功能和逻辑都足够复杂，并发量很大，甚至需要多台服务器进行负载平衡，且一般有一定的应用集成需要的、需要大量人员参与构建的软件。这样的软件其价值非常可观。通常大家都与“企业级应用软件”的概念相互套用。所以，我下文中用“企业级应用软件”来替换原文中的“大型软件”。

现实中的解决方案
在Java的世界里，企业级应用软件自然就使用J2EE方案。比较通用的J2EE解决方案是采用EJB，并采用JDO之类的技术做持久化。由于EJB固有的缺陷，现在用 EJB的人越来越少了。原因大家看看Rod Johnson的《J2EE Development without EJB 》应该自然就明白了。但是没有人会推荐在J2EE中直接使用Statement来直接进行持久化，或者对Statement进行一些简单的封装做一个所谓的“通用的持久层”。当然，Hibernate取得了巨大的成功，所以Hibernate3就自然成了JSR的一部分。如果不是因为企业应用的需要，Hibernate其实是没有市场的。
回到.net里。若干年前，当我听说Microsoft打算在SQL Server 2005中实现ORP(Objective-Relational Persistence)的时候，我兴奋了一阵，但事实上最后Microsoft并没有实现这个诺言，就象Microsoft也没有向业界交付 Object-Spaces一样。这可能是对ORM持保守态度者的主要依据来源。大家都是通过最原始的方案或者简单的封装(包括企业库中的DAAB)来实现数据访问。这些Helper类被渗透到应用程序的每一个部分，甚至完全耦合。
就象J2EE当年的景象一样，大家都在等待.Net中的 Hibernate，在等待中纷纷动手做自己的ORM。在这个过程中冒出来一堆优秀的、商业化的框架，例如ECO、XPO、DataObjects等等。这些框架设计精妙，性能优异。当然也出现了很多优秀的开源框架，例如Neo。它们都各有千秋，有一些功能强大，但结构复杂。有一些功能较弱，但结构简单且易于使用。
Microsoft已经让我在ORP上面失望过一次。我不知道会不会在DLinq上再让我失望一次。我不象某些人那样乐观。

持久层的意义
持久层其实只是一个应用程序中很小的一部分，在应用程序中的地位远不象某些人所描述的那样关键。如果你的设计中系统的分层非常好的话，只有业务逻辑才需要 ORM，因为表现层应该是完全不关心持久层的。相反，如果你的系统不分层，ORM的确一点意义也没有。所以，其实小的系统根本不需要ORM。这些系统往往两三个人就可以完成，他们可以直接在页面上使用Native的SQL语句访问数据。呵呵，在Microsoft平台，大量的开发人员都是这么过来的。
但是企业级应用，不分层是无法完成的。每个细小的功能都需要分给三个或者更多的人来完成。如果不分层，则完全无法控制。如果分层的话，在业务逻辑层甚至表现层再直接访问数据库就成了不可思议的事情。这时候，ORM就成了你不多的选择之一。
随着系统越来越庞大，系统对于可维护性、可集成性、可扩展性、可测试性的需要也越来越强，对分层的需要也就越来越迫切。其中任何一个特性的需要，离开ORM都无法很好地实现。

ORM的哪些方面被人指责
性能。大多数人想当然地认为ORM都是性能拙劣，仅仅因为他们用过了NHibernate。我没有用过NHibernate，我无法评价 NHiberbate的性能。但是我知道，ORM对性能的影响是极其有限的，如果造成性能问题，往往都是因为使用不当。即使你直接使用ADO.NET也一样会冒出性能问题来。相反，由于Cache的原因，ORM事实上通过空间的牺牲换取了大量数据库访问性能的提升。当然，这要求框架本身实现了这一功能，并且正确地使用。相反，没有ORM的Helper是很难实现Cache的。
使用难度大。我不知道大家如何看待Hibernate的使用。最初的、干净的、不带任何第三方工具的Hibernate完全依靠手工编撰映射文件和POJO代码。即使如此还是有大量的人来使用。而现在的ORM框架多数都提供了这样的工具，帮助你很好地利用框架提供的功能。其实除了对面向对象方面知识和思想的要求，使用ORM后的业务对象来使用。因为通过ORM来编写业务逻辑几乎比任何一种Helper的方式都简单。相反十年前撰写和调试存贮过程的回忆每每让我如恶梦一般。
不稳定。其实持久层是一个很局部的东西，整体上并不复杂。只要有足够的测试就可以保证框架本身的稳定性。如果框架本身稳定，不太可能因为持久层的原因导致系统不稳定。

ORM到哪个程度最合适
大量的开发人员实现了自己的简单的持久层。如果太简单，没有什么意义。如果太复杂往往并不实际。首先，必须真的提升了开发效率，必须切实解决了团队开发中的耦合问题。其次，具有足够的可扩展性。最后，必须提供基本的工具。

结论
不要再提“大型系统”不适合使用ORM的说法了，要知道，ECO就是专门针对“大型系统”的。相反，小系统才完全没有必要使用ORM。

ORM 之硬伤

园子里有些人，他们真以为自己明白了面向对象，然后装着满腹经纶，侃侃而谈，一篇接一篇，不厌其烦地喊着ORM 如何如何。你以为他真的明白“面向对象” 么？其实，他对面向对象的理解仅限于教科书中的封装、继承和多态，或者再知道一点面向对象的若干原则但其实并不真正理解。
笔者愚钝，入行多年尚不懂面向对象，只懂得用其形而不懂用其实。五年后的某一天终于开窍，明白了面向对象之实，也仅仅是一个开始而已。当又经历了另一个五年的倦怠，发现并理解了设计模式、面向方面等技术作为面向对象的必要补充后，才算是彻悟！所以当我见过一个同学，尚未出校门已然彻悟，真是羞愧！
有一天面试的时候，我问一位同学，Framework和Library的区别是什么？他答不上来。而另一个同学略一思考就告诉我，你的程序会调用Library，而 Framework会调用你的程序。虽然精辟，但我还是要补充：Framework通常也会提供一个Library，所以，Library是水平的，而 Framework是垂直的，此处的“水平”和“垂直”是相对应用系统的层次设计而言的。如果没有层次，其实Framework其实就是Library。 Microsoft的Enterprise Library当然就是一个Library，无法代替Framework。
如果让那位已经彻悟的同学舍弃ORM 来实现复杂的业务功能，他当然无法接受。相反，如果让一位抱着《Thinking in Java》似懂非懂的同学用ORM 来实现同样的功能，他也一样无法接受。其中的一些同学非常擅于“鸡蛋里挑骨头”，于是园子里有了这样一堆垃圾文章或者垃圾跟贴。另外一些同学不精于这样的能力，所以仍在徬徨之中。

此乃ORM 惟一之硬伤也！ 如果你不理解面向对象思想，就先试着去理解，然后再来讨论ORM 这个话题，并发表你的高见。

再说性能
ORM 提供了所有SQL语句的生成，代码人员远离了数据库概念。从一个概念需求(例如一个HQL)映射为一个SQL语句，并不需要什么代价，连1%的性能损失都没有。真正的性能损失在映射过程中，更具体地讲，是在对象实例化的过程中。我曾经做过一个试验，以“计算第N个素数”这样的命题。我采用Delphi写 Native Win32 Console程序，又采用C#写CLR Console程序。两者相比，令我大失所望。

N	结果	耗时
N	结果	Delphi	C#
1000	7927	0ms	2ms
10000	104743	16ms	17ms
100000	1299721	438ms	324ms
1000000	15485867	11437ms	7823ms

该命题采用的算法是找出第N个素数以前的所有素数，开辟一个内存区存贮这些素数。在Delphi中我用链表，在C#中我用 List<int>。实际的结论是：当列表足够大时，链表的性能远不及List<int>。当然，如果每个链表节点只装一个元素，这种差异会更明显。事实上，我测试过每个链表节点所装的元素个数做了一个阶梯试验，从30个、254个、510个、1022个到2046个，每个节点所装载的元素数越多，耗时越短，最终越来越接近C#的List<int>。
不知道各位是否已经明白了性能在哪儿损失了：内存分配。 Native的内存分配与释放都是非常耗时的操作系统行为。但在托管环境下，内存的释放是GC干的事情，甚至不需要统计到耗时中，而内存的分配也是一件非常快捷的事情。当然，即使是快捷也还是需要耗时的。这让我联想到DataSet的性能。DataSet也是一种数据容器，但是却没有多少人抱怨 DataSet的性能。如果你明白DataSet的机制，就会发现，DataStorage巧妙地规避了内存分配和耗时的问题。而我们的ORM 无法解决每个对象实例在构造时分配内存所耗时间。我做了一个不精确的评估，相比DataSet，对象集合的性能损失大约占20%左右。
如果假定ORM 并没有比传统的数据访问方式耗费额外的IO的话，除此之外，ORM 再没有任何性能损失！
再回到前提条件：ORM 并没有比传统的数据访问方式耗费额外的 IO。这个条件成立么？
“由于ORM 的实体对象定义已经固定，所以即使我不需要某些字段，也一样需要加载这些字段。 ”
OK，有的同学已经看出来了。额外定义一个视图的实体对象即可。定义这些视图的实体对象的确很麻烦，但是肯定比构造那些SQL并不断地维护它简单得多。
“当一张表中有1000万行数据时，实例化1000万个对象是不可能的。 ”
非常正确。难道你曾经成功地尝试过将1000万行数据加载到某个DataTable中并且没有性能问题？从应用的角度来说，在一个模型中包含的实例数超过500行就有设计不当的嫌疑。我对Google的抱怨是：当搜索结果超过1000个时都会令我抓狂。让我从1000行数据中找出我所需要的某一行，这是开发人员的思维，并不是用户的思维。如果能够在已有的结果中进行二次、三次或者多次进一步的筛选，可能更适合绝大多数人。我为什么不愿意在分页中花太多的精力，其原因也是如此。我认为用户的眼球只能接受100行以内的数据，超过这个行数就需要采用其它的方式，或者改善领域设计。所以，这个问题的答案是：你不可能需要一次载入1000万行。
“当应用系统整体性能欠佳时，因为隐藏了数据访问细节，从而无法找到快速优化的途径。 ”
不能同意。几乎每一个ORM 框架都提供了非常可靠的数据库访问日志。通过这些日志分析性能损失将比直接使用SQL语句更可靠、更方便。

灵活性
ORM 不够灵活？我完全不能理解，我甚至不知道这个不够灵活是与什么基准相比。相反，ORM 可以让你灵活地替换数据库(当然这个优点并没有非常重要的意义)；在修改数据库以后不需要修改服务层或者只需要进行简单的修改；可以对某个服务进行单独的测试；可以对服务进行不依赖数据库的、上下文一级的扩展；可以进行更好的层次设计；......
不能实现所有的查询条件
如果是想表达“每一个Select语句可以通过面向对象的方式进行查询”的话，我觉得目前绝大部分ORM 框架都已经很好地解决。我解决这一问题的基础是：我不提供超越SQL ANSI92的能力，但覆盖SQL ANSI92的所有功能。对于解决实际应用中的不足部分，采用运行时算法补充。Hibernate采用的是HQL这样的方式，基本上SQL能够做到的，HQL都无一例外可以做到。ECO采用的是OCL的方式，其功能可以完全覆盖SQL。我的框架所实现的查询目前我还没有发现无法解决并必须利用 Native SQL来实现的(因此我无法理解Hibernate3为什么要提供这样的扩展)。Hibernate采用的策略是以面向对象为核心，换句话说，以持久化对象为终极目标，而以加载对象以持久化对象为前提。设计一个POJO，实例化，然后保存起来，下次使用的时候可以依样载入即可。大规模的查询并不是框架的核心目标。所以，如果你完全依赖Hibernate去持久化，我非常担心你将来是否有机会用你的数据积累去做数据仓库。而我的框架目标则不同。在持久化与加载两个目标间我没有主次之分。我也没有超前到MDA，我的对象模型仍然基于数据库的ER设计，我仍然提供一组非常清晰明了的数据库视图。
多表连接查询
如果需要将多表的连接查询结果转换成一个二维视图，显然需要你再定义另一个视图实体对象，将视图映射到对象模型。如果你仅仅是要在一个对象实例的某个属性中获得另外一个对象的集合，似乎这不是DAL方式的优势，而反而是ORM 的优势。将多个对象所依赖的多个对象放到同一个上下文中，显然这是最好的一种方式。
统计查询
从理论上讲，ORM 不适合做OLAP，不适合做太多统计查询。其实这一点，我的框架已经提供了非常好的解决方案，对Aggregate到面向对象的视图处理得非常好。

开发效率
提高开发效率仅仅是一个抽象的目标，具体的手段应该是两个方面：一是IDE和辅助工具；一是适合将任务分解成多个解耦的部分从而可以通过增加人员来提升总的开发效率。虽然ORM 仅仅是开发环节中很小的一部分，但是却遍布应用系统中的每一角落，因而对开发效率影响较大。除了ORM ，难道还有更好的选择么？
ORM 后，原来精湛的SQL技能变得毫无用武之地，让人甚是失落，但这并不是ORM 的过错。

关于数据库 crud(create retrieve update delete) 自动化辅助工具，其中的翘楚必然是 orm( 对象 - 关系映射 ) 工具。

　　hibernate,activerecord 分别可以说是发挥了 java,ruby 语言哲学到极致的工具，其他动态语言的 orm 工具大都参考这两者的架构和模式，使用他们的前提是掌握面向对象基础（面向对象 3 原则及应用）和数据库应用基础（设计范式和 SQL 语言）。

　　相对简单一点的是根据数据库中获得的表结构实现简单 crud 功能的库，但是因为功能太简单，对于处理表和表之间的关联关系力不从心，在我的实际经验中很早就废弃了。

　　说回静态语言， c++ 语言目前为止没有完整案例的 orm 工具，因为 c++ 标准库并不提供完整的反射库，只提供了基础的 RTTI 。没有反射库就写不出 orm ，所以虽然有一小撮分子研究过自己写反射库，再写 orm ，不过都流产了，要么就变形了——利用有限的功能变相实现部分功能，在 joel 的博客上有人发了 c++ orm 的讨论，应者寥寥，讨论中说到的类库俺看了下，都不完整。

　　那么静态语言就真的不行了？受中国亿万开发人员拥护的宝兰公司（ IDE 部分已经因为入不敷出分拆出 codegear 公司）的王牌设计师 Anders （亦为微软设计了 .net ）所设计开发的 vcl 库，拥有足够的反射能力，国内一个 delphi 开发者 yyanghhong 据此开发出了一个 orm 工具，据他最后 javaeye 的帖子中说，将参考 hibernate 的结构实现 delphi 版的 orm ，不过也有 1 年多未有消息了――可能和我一样， 1 年前发布的改 hibernate 和 tomcat 的模块后，也有人问过我相关知识，但一个一直为吃饭忙乎的人是顾不上了。另有一位网友提供了一个开源的delphi orm emvc ，目前只出到1.03alpha版，我还没用过。