看了近一段时间cnblogs那么多关于O/R Mapping的文章，忍不住也想发表一下自己的看法。

首先我觉得O/R Mapping和面向过程没有什么关系。他的作用是

在面向对象程序设计过程中，如果涉及到对大量的对象实例进行筛选操作时，用来维护对象实例的生命周期的作用。

我来解释一下我这句话的意思。假如说我们现在有一个BBS系统，按照常理来讲：每一个帖子是一个帖子类的实例。

class Topic {

string Title;

string Content;

Author Author;

}

假如现在有人发新贴了，那么内存中会实例化出

TopicCollection.Add(new Topic("名称","作者","标题")); 当要有选择的显示帖子列表的时候我们会动态遍历帖子集合TopicCollection，找到我们需要的帖子显示出来。这就是我们所说的业务逻辑层，可是这样做有一个致命的弱点就是如果我们重起机器，或是帖子集合过大内存溢出了，我们就不能保存以前的内容，所以我们换一种方式就是将这些信息保存在磁盘上。比如：你可以写一个文本文档用自己的算法保存，或是保存在通用的数据库里面。而当我们需要读取的时候会自动加载这些信息，并将它实例化到我们的内存当中，然后业务逻辑会处理这些实例化的对象。整体过程有些像对象的序列化和反序列化。

而O/R Mapping的过程就是将对象实例化并加载信息的过程。当然这里的R（Relation）是指关系数据库的意思。

无论我们是O/R也好，R/O也罢。这都不是关键，谁说我们先做数据库再做领域模型，设计出的软件就不好了？O和R是没有关系的。他就好比：两个格式不同XML文档进行样式表转换一样。

我也看到一些人说，为了Mapping我们会多写出一些 xxxManager / xxxProvider 等等的类或者什么Save、Load的方法，好像很不面向对象并且这和领域模型没有关系。

其实不然，我们来想象一个场景：一个档案管理中心，当你把你的档案交给管理中心的时候，管理员会根据你的档案内容按一定规律（算法，比如按名字字母的顺序）放在符合条件的档案柜里，如果你因为一些原因要取走档案的时候，管理员又会根据相关条件从档案柜里将你的档案从档案柜里取出来交还给你。难道这些过程都不属于业务逻辑？

答案是肯定的。但对于这种业务逻辑我们一般封装在数据层，因为这样会提高很多效率，例如：假如我们对新闻进行筛选，要找出所有点击量大于10000的新闻列出来，按理论来说这应该是业务逻辑，我们应该把这种筛选放在业务逻辑层，具体做法我们先将所有新闻信息从磁盘中读取出来（数据库也是把信息保存在磁盘中的），然后根据这些信息实例化新闻类news，并将这些实例负值放入新闻集合类的实例中。最后遍历这个新闻集合实例的所有新闻实例，并判断其属性ViewTimes大于10000的显示出来。

好这个方式非常符合将系统分层的理论，可是这种方式的可行性可想而知（如果记录量大的化，肯定会内存溢出），所以这时我们不得不把对信息筛选的过程放入数据层（把对信息筛选的业务逻辑放入数据层）。然后将数据层计算好的结果（记录集）进行对象实例化，再将其进行其他的逻辑处理（在以数据为中心的应用中，往往这里已经没有什么业务逻辑。因为大多数的业务逻辑都是对数据的筛选。）。

不好意思说到这里好像有些走题了，而关于O/R Mapping，O和R没有任何关系，他既不属于面向对象也不属于面向过程，他只相当于一个转换方程式。领域模型和数据库在开发过程中，其实完全可以齐头并进（条件是在对需求认知一样的前提下），而O/R Mapping在其中执行转换的操作。

这是我目前对一些项目的开发认识。可能有很多不对的地方，希望大家给予批评指教。谢谢……