第一种是用于关系数据库和业务实体对象之间的映射的ORM对象关系映射(Object Relation Mapping，简称ORM或O/RM，或O/R mapping ) 效果是，创建了可以在编程语言中使用的“虚拟对象数据库”。 简言之，就是将关系数据库封装为业务实体对象。 这样，在具体处理业务对象时，就不需要与复杂的SQL语句进行交互，从而可以轻松地操作对象的属性和方法。
“对象映射”(Object-Relational Mapping )提供了一种概念性的友好的建模数据方法。 ORM方法论基于三个核心原则：
简单：以最基本的形式对数据进行建模。 传递性：数据库结构以任何人都能理解的语言记录。 准确性：根据数据模型创建精确标准化的结构。 典型地，建模者通过从熟悉APP应用但不熟悉数据结构的人那里收集信息来开发信息的模型。 建模者必须能够使用非技术人员能理解的术语在概念级别与数据结构进行通信。 建模者也必须能够在简单的单元中分析信息和处理示例数据。 ORM旨在改善这种联系。 简单地说，ORM相当于中继数据。
二是理解ORM对象-关系映射(Object-Relational Mapping，简称ORM ) )是伴随着面向对象软件开发方法的发展而产生的。 面向对象的开发方法是当今企业APP应用开发环境下的主流开发方法关系数据库是企业APP应用环境下持久存储数据的主流数据存储系统对象和关系数据有两种表示形式：业务实体，它们在内存中表示为对象，在数据库中表示为关系数据。 内存中的对象之间存在关系和继承关系，但在数据库中，关系数据不能直接表达多对多的关系和继承关系。 因此，对象-关系映射(ORM )系统一般以中间件的形式存在，主要实现程序对象到关系数据库数据的映射。
面向对象是根据结合、聚合、封装等软件工程的基本原则发展起来的，关系数据库是从数学理论发展起来的，两种理论有明显的区别。 为了解决这种不一致性，对象关系映射技术应运而生。
从信用证开始吧。 o从对象(Object )开始，r来自关系)。 大多数程序都存在对象和关系数据库。 在业务逻辑层和用户界面层，我们是面向对象的。 当对象的信息发生变化时，需要将对象的信息保存在关系数据库中。
zxdxm在不使用o/r映射的情况下开发APP应用程序。 您可能会为许多数据访问层编写代码，以便从数据库中保存、删除以及读取对象信息。 你在DAL上写了很多方法来读取对象的数据，或者改变状态的对象。 这些代码总是重复写的。
当你打开最近的程序查看DAL代码时，你一定会看到很多近似的通用模式。 例如，考虑一下如何保存对象。 传递对象，将SQLPARAMETER添加到SQLCOMMAND对象，使所有属性和对象相对应，将SQLCOMMAND的COMMANDTEXT属性设置为存储过程为每个对象重复写这些代码。
除此之外，还有更好的方法吗？ 是的，部署o/r映射。 实质上，一个O/R Mapping会为你生成DAL。 与其自己写DAL代码，不如用O/R Mapping。 您在O/R Mapping中保存、删除和加载对象，O/R Mapping负责生成SQL。 你只需要在意对象就行了。
典型的ORM包括以下四个部分：
对持久性对象进行CRUD操作的API； 语言或API用于指定与类和类属性相关的查询。 一种技术，通过该技术，可以将用于定义映射元数据的工具ORM的实现与事务对象一起进行直接检查、跟踪辅助功能和其他优化操作。 三、ORM的优缺点ORM自其概念提出以来，得到了无数响应，花样繁多的应用框架更是应接不暇。 你会发现他有独特的优势。 他的优势是什么呢？
第一个：
ORM的最大优点是隐藏数据访问细节，“封闭”的通用数据库交互，是ORM的核心。 他使我们的通用数据库的交互变得简单，完全不用考虑该死的SQL语句。 被迅速开发，来自那里。 第二：
ORM使我们能够轻松构建固化数据结构。 在ORM年表的历史时期，需要将对象模型转换为一个个的SQL语句，然后通过直接连接或DB helper在关系数据库中构建数据库体系。 目前，基本上所有的ORM框架都提供了从对象模型构建关系数据库结构的功能。 这个，相当好。 世上驴不吃草(三思而后行，买老驴不吃草)，任何优势背后都不可避免地隐藏着缺点。
第一个：
必然地，自动化意味着映射和相关管理，意味着牺牲性能(在早期，这在所有讨厌ORM的人中都是如此) 当前的各种ORM框架尝试了各种方法来减轻这种(LazyLoad，Cache )，但效果显著。 第二：
面向对象的查询语言(X-QL )作为数据库与对象之间的转移，隐藏了数据库级的业务抽象，但不能完全屏蔽数据库级的设计，必然会增加学习成本。 第三：
对于复杂查询，ORM仍然无能为力。 可以实现，但没有价值。 视图解决了大多数计算列、案例、组和having。
order by, exists，但是查询条件(a and b and not c and (d or d))。。。。。。 四，正确看待ORM ORM为何而生在数月以前，我有幸参加了一个公司内部的组件发布会。令我深感意外的事，一向无人关心的组件发布会这次变得人山人海，在漫长的新版本介绍之后。每个开发组长都跳出来抱怨上一个版本的问题，并且宣布与刚发布的新版本也是无法满足他们的需要的。一切都是如此的混乱，以至领导层不得不采用镇压的方式来平息怒火冲天的人们。
在会后的那个晚上，我仔细回想了这次冲突。因为据我了解，这一系列的组件非常完美的完成了他所被期待的功能。可是为什么还是会被抱怨如此那。
我觉得，可能，他(组件)是没有被正确使用了。
不知道还有谁记得James Elliott的那句话：
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工具，难道真的一无是处了？
ORM与DB Helper Library很多人可能都接触过这类的helper，每个公司都有自己的helper。许多Helper提供了很多的强大的功能，封闭交互底层，实体类支持，提供SQL翻译功能。ORM比之这些Helper只是多提供了一层，他尝试封闭的自动化的（或是映射文件）来实现关联。以前，这都是我们手打的。（灵活替换数据库也算ORM优点，ORM优势和缺点。。。（小雨））
问题就在与有些人发现封闭的自动化关联满足他们需要了，所以ORM对他而言是成功的。而有些人发现封闭的自动化关联不适合他们的项目，所以ORMgtdxq。
我的观点是ORM试图取代helper，为此提供了更多的功能。他为了应付更加严格和复杂的企业需求而不断发展，在很多情况下，这些工具开始具有自身的复杂性，使得开发人员必须学习使用它们的详细规则，并修改组成应用程序的类以满足映射系统的需要，使用它们所面临的复杂性反而盖过了所能获得的好处。在我们的大部分项目中Helper依然是我们构建数据持久层的主力，ORM或许在有些项目(模块)中可以独揽一切，但是ORM（就目前而言）无法面对一切考验。
五，数据持久化上面有提到很多人使用ORM的框架构架项目的数据持久层，什么事数据持久层？这就要理解数据持久化了。
理解数据持久化数据持久化就是将内存中的数据模型转换为存储模型,以及将存储模型转换为内存中的数据模型的统称. 数据模型可以是任何数据结构或对象模型,存储模型可以是关系模型、XML、二进制流等。
狭义的理解，持久化仅仅是指把对象数据永久保存在数据库中，数据在计算机中一般由两个存储地，内存为暂存，数据库可以理解为永存；广义的理解，持久化包括和数据库相关的各种操作，封装了数据访问细节，为大部分业务逻辑提供面向对象的API。
简单的理解持久化可以在二个层面：应用层和系统层：
应用层：如果关闭(shutdown)你的应用然后重新启动则先前的数据依然存在。系统层：如果关闭(shutdown)你的系统（电脑）然后重新启动则先前的数据依然存在。 数据持久化好处使用数据持久化有以下好处：
1、松散耦合，程序代码重用性强，使持久化不依赖于底层数据库和上层业务逻辑实现，更换数据库时只需修改配置文件而不用修改代码。2、业务逻辑代码可读性强，在代码中不会有大量的SQL语言，提高程序的可读性。3、持久化技术可以自动优化，以减少对数据库的访问量，提高程序运行效率。数据持久化对象的基本操作有：保存、更新、删除、查询等。
由此可知，数据持久层也就是与数据交互的那一层次，所以有时候有见到ORM框架介绍：是一个数据持久层(ORM)框架。
本文第三节第四节：摘自ORM的优缺点
另大部分：摘自百度百科