对象关系映射（Object Relation Mapping，简称ORM，或O/RM，或O/R mapping），用于在关系型数据库和业务实体对象之间作一个映射。从效果上说，它其实是创建了一个可在编程语言里使用的“虚拟对象数据库”。说白了就是把关系型数据库封装成业务实体对象，这样，我们在具体的操作业务对象的时候，就不需要再去和复杂的SQL语句打交道，只需简单的操作对象的属性和方法。
对象关系映射（Object-Relational Mapping）提供了概念性的、易于理解的模型化数据的方法。ORM方法论基于三个核心原则：
|
1 2 3 |
简单：以最基本的形式建模数据。 传达性：数据库结构被任何人都能理解的语言文档化。 精确性：基于数据模型创建正确标准化的结构。 |
典型地，建模者通过收集来自那些熟悉应用程序但不熟练数据结构的人的信息开发信息的模型。建模者必须能够用非技术专家可以理解的术语在概念层次上与数据结构进行通讯。建模者也必须能以简单的单元分析信息，对样本数据进行处理。ORM专门被设计为改进这种联系。简单的说：ORM相当于中继数据。
对象-关系映射（Object-Relational 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，你只需要关心对象就好。
一般的ORM包括以下四部分：
|
1 2 3 4 |
一个对持久类对象进行CRUD操作的API； 一个语言或API用来规定与类和类属性相关的查询； 一个规定Mapping METADATA的工具； 一种技术可以让ORM的实现同事务对象一起进行DIRTYCHECKING, LAZY ASSOCIATION FETCHING以及其他的优化操作。 |
ORM自其概念被提出，就得到了无数的响应，花样繁多的应用框架更是应接不暇。可见，他是有其独到的优势的。那么他的优势有哪些那：
第一：
|
1 2 |
ORM最大的优势，隐藏了数据访问细节，“封闭”的通用数据库交互，ORM的核心。 他使得我们的通用数据库交互变得简单易行，并且完全不用考虑该死的SQL语句。快速开发，由此而来。 |
第二：
|
1 2 |
ORM使我们构造固化数据结构变得简单易行。在ORM年表的史前时代，我们需要将我们的对象模型转化为一条一条的SQL语句， 通过直连或是DB helper在关系数据库构造我们的数据库体系。而现在，基本上所有的ORM框架都提供了通过对象模型构造关系数据库结构的功能。这，相当不错。 |
世上没有驴是不吃草的(又想好又想巧,买个老驴不吃草)，任何优势的背后都隐藏着缺点，这是不可避免的：
第一：
|
1 2 |
无可避免的，自动化意味着映射和关联管理，代价是牺牲性能（早期，这是所有不喜欢ORM人的共同点）。 现在的各种ORM框架都在尝试使用各种方法来减轻这块（LazyLoad，Cache），效果还是很显著的。 |
第二：
|
1 2 |
面向对象的查询语言(X-QL)作为一种数据库与对象之间的过渡,虽然隐藏了数据层面的业务抽象, 但并不能完全的屏蔽掉数据库层的设计,并且无疑将增加学习成本. |
第三：
|
1 |
对于复杂查询，ORM仍然力不从心。虽然可以实现，但是不值的。视图可以解决大部分calculated column，case ，group，having,order by, exists，但是查询条件(a and b and not c and (d or d))。。。。。。 |
在数月以前，我有幸参加了一个公司内部的组件发布会。令我深感意外的事，一向无人关心的组件发布会这次变得人山人海，在漫长的新版本介绍之后。每个开发组长都跳出来抱怨上一个版本的问题，并且宣布与刚发布的新版本也是无法满足他们的需要的。一切都是如此的混乱，以至领导层不得不采用镇压的方式来平息怒火冲天的人们。
在会后的那个晚上，我仔细回想了这次冲突。因为据我了解，这一系列的组件非常完美的完成了他所被期待的功能。可是为什么还是会被抱怨如此那。
我觉得，可能，他(组件)是没有被正确使用了。
不知道还有谁记得James Elliott的那句话：
|
1 2 3 4 |
As good object-oriented developers got tired of this repetitive work, their typical tendency towards enlightened laziness started to manifest itself in the creation of tools to help automate the process. When working with relational databases, the culmination of such efforts were object/relational mapping tools. |
ORM构架只能是一个helper，他定位与此，而不是完整的数据持久层。他的设计者从来就没把他定位于取代一切的超级美女。ORM致力为长久以来的程序员与”重复劳动”的战争而助拳。与任何一个helper一样，他有自己的不足，他有优点也有缺点。
无数的开发人员试图将使用ORM的框架构架自己项目的数据持久层，很多人感受到了ORM的优势，他们欢心鼓舞。但是很不幸，也有很多人失败或是深受蹉责。
还有许多人，无奈的编写着很多ORM不适合作的事情。其实想一想，被自己舍弃了的以前的helper工具，难道真的一无是处了？
很多人可能都接触过这类的helper，每个公司都有自己的helper。许多Helper提供了很多的强大的功能，封闭交互底层，实体类支持，提供SQL翻译功能。ORM比之这些Helper只是多提供了一层，他尝试封闭的自动化的（或是映射文件）来实现关联。以前，这都是我们手打的。（灵活替换数据库也算ORM优点，ORM优势和缺点。。。（小雨））
问题就在与有些人发现封闭的自动化关联满足他们需要了，所以ORM对他而言是成功的。而有些人发现封闭的自动化关联不适合他们的项目，所以ORM被诟病。
我的观点是ORM试图取代helper，为此提供了更多的功能。他为了应付更加严格和复杂的企业需求而不断发展，在很多情况下，这些工具开始具有自身的复杂性，使得开发人员必须学习使用它们的详细规则，并修改组成应用程序的类以满足映射系统的需要，使用它们所面临的复杂性反而盖过了所能获得的好处。在我们的大部分项目中Helper依然是我们构建数据持久层的主力，ORM或许在有些项目(模块)中可以独揽一切，但是ORM（就目前而言）无法面对一切考验。
上面有提到很多人使用ORM的框架构架项目的数据持久层，什么事数据持久层？这就要理解数据持久化了。
数据持久化就是将内存中的数据模型转换为存储模型,以及将存储模型转换为内存中的数据模型的统称. 数据模型可以是任何数据结构或对象模型,存储模型可以是关系模型、XML、二进制流等。
狭义的理解，持久化仅仅是指把对象数据永久保存在数据库中，数据在计算机中一般由两个存储地，内存为暂存，数据库可以理解为永存；广义的理解，持久化包括和数据库相关的各种操作，封装了数据访问细节，为大部分业务逻辑提供面向对象的API。
简单的理解持久化可以在二个层面：应用层和系统层：
|
1 2 |
应用层：如果关闭(shutdown)你的应用然后重新启动则先前的数据依然存在。 系统层：如果关闭(shutdown)你的系统（电脑）然后重新启动则先前的数据依然存在。 |
使用数据持久化有以下好处：
|
1 2 3 |
1、松散耦合，程序代码重用性强，使持久化不依赖于底层数据库和上层业务逻辑实现，更换数据库时只需修改配置文件而不用修改代码。 2、业务逻辑代码可读性强，在代码中不会有大量的SQL语言，提高程序的可读性。 3、持久化技术可以自动优化，以减少对数据库的访问量，提高程序运行效率。 |
数据持久化对象的基本操作有：保存、更新、删除、查询等。
由此可知，数据持久层也就是与数据交互的那一层次，所以有时候有见到ORM框架介绍：是一个数据持久层(ORM)框架。
from:https://blog.csdn.net/u012585964/article/details/52412520