结束无谓的讨论吧

上周园子里对ORM的讨论达到高潮

O/R Mapping再乱弹 http://www.cnblogs.com/hBifTs/archive/2006/06/09/421997.html
也谈谈ORM http://www.cnblogs.com/okokwukai/archive/2006/06/08/420563.html
对ORM的疑问 http://www.cnblogs.com/xhp5678/archive/2006/06/08/420435.html
也谈谈我对ORM的看法 http://www.cnblogs.com/nomagic/archive/2006/06/07/420018.html
O/R Mapping乱弹 http://www.cnblogs.com/idior/archive/2006/06/07/419999.html

很可惜大部分从理解就有问题，结论自然就不必看了，值得看的是idior的这篇 <O/R Mapping乱弹>  ，很有见地，但评论最终还是落入了错误的讨论。

我不想卷入这场激烈而无谓的辩论，于是写这篇随笔，小心求证我的观点。

首先说说什么是ORM(这个东西每周都有人写随笔入门一下，但是很可惜，大部分人看了点其他人的随笔就认为自己知道了，所以这场讨论是以讹传讹的最终结果)

一、实质
[ORM的全称是Object Relational Mapping，即对象关系映射。它的实质就是将关系数据（库）中的业务数据用对象的形式表示出来，并通过面向对象（Object-Oriented）的方式将这些对象组织起来，实现系统业务逻辑的过程。] 摘自《Grove——.NET中的ORM实现》 http://www.microsoft.com/china/MSDN/library/netFramework/netframework/Grove.mspx?mfr=true
ORM实质是一种机制，在面向对象的系统设计中把对象持久化到关系型数据库，和从关系型数据库中获取对

象（包括对象间关系）。

二、基础
基于以上观点，很容易看出ORM的基础是“面向对象系统设计”。（很多对于ORM的讨论从这里出错，下面讨论）

三、源起
“当我们使用面向对象技术建立好了我们的领域模型，一个问题随之而来，对象如何持久化？”<O/R Mapping乱弹>。

四、产生
既然整理出源起，那么产生就显而易见了。任何为了解决源起所描述的问题的解决方案都是ORM。

五、解决方案
解决方案很多，包括自己写数据访问层将对象持久到数据库，也包括使用其他ORM工具（框架）完成此过程。

六、总结
根据以上结论，所有的面向对象设计的把对象持久到数据库的系统都必须使用ORM。

七、错误
1、非面向对象设计的系统。“所以当你不是用对象的方法(不是说你仅仅使用了面向对象语言)来分析解决问题时请离O/R M远一点，这样对大家都好。你不会觉得它奇怪，它也不会被你用的郁闷。”《O/R Mapping乱弹》如果你不想买火柴，你还会跟商家讨论火柴盒里的火柴头应该是红色还是蓝色么。

2、ORM性能如何？注意ORM是机制不是工具，虽然有些工具完成了此功能。很多人通过了ORM工具才认识ORM这个概念，包括我自己。但是想想工具为何产生。

3、O->R or R->O？这个问题涉及到项目管理了，系统由谁设计，是不需要关心使用何种数据库的设计师，还是对数据库一知半解的程序员，还是二者的综合体？回想一下是不是有时候因为我们对一些必备知识的不足而去修改已经设计好的东西。

4、ORM不适合大项目开发。这句话是个伪命题，对于面向对象且基于数据库的设计，ORM是必须实现的，可以选择的只是选择何种ORM方案。而对于不进行面向对象设计的系统，根本无从谈到ORM。其实面向对象更适合大项目的开发。

5、ORM影响领域模型设计。“显然我们希望能够更多的关注与领域模型而非这些对象生命周期的管理，此时O/R M的需求应运而生，而能够透明的实现对象的持久化和反持久化则更为我们所追求，此时再来看看某些使用O/R M来为一个领域对象实现Save Load的做法是多么与我们的想法背道而驰，这些方法与领域何关？”。Idior的意思是很多人误用ORM进行设计。事实上我并不认为Save Load有什么不好，而如果进行更细致的系统设计，把方法和数据分离，完全没有问题，可以看我另外一篇文章http://pblee.cnblogs.com/archive/2006/05/24/407881.html