From: http://blog.robinzhong.com/index.php/archives/2006/06/09/112.html
idior 前两天在cnblogs发表了一个关于O/RM的文章 “O/R Mapping乱弹”.
呵呵,他来乱弹,我也来弹弹.
对于O/RM还是R/OM.正如你在文中提到的,O/R M这个概念是从Java社区传过来的. 在这之前, M$这一块是没有这样的事物可以对应的.
因为Java正火的时候,M$还在推行当时的Windows DNA架构.Windows DNA的架构就是一个C/S式的架构,使用COM/COM+等来完成远程通讯.
但是后来因为基于Internet的B/S结构的流行,使得Windows DNA推行的并不是太成功.
M$看着Java在企业的应用很流行,于是开始偷偷的学,也想进入企业级的开发领域,于是就有了.NET ( 当然,这个只是偶的猜测.也有人说,Win32API到现在已经很好了,不过缺陷却是Procedure试的开发,不是当时正在流行的OO式的开发.于是 ,对这一些低层的Win32 API进行了OO式的封装,于是有了.NET fx.后来追求完美的人发现C++太复杂了,于是便发明了新的C#)
但是当时M$在企业的开发领域还不是太了解,没办法挤进去.所以只好以曲线救国的方式. 从农村包围城市,先让开发者都学会.NET,从小的项目做起.
为了给大家提供一个.NET下面开发的参考,M$使用是最直接,最容易明白的方式 — 以数据库为中心.
以数据库为中心,指是的设计的原则.
在Design开始前, 根据Requirement来定义数据结构,然后把数据结构反映到数据库中去.通过数据在db中的关系(PK/FK之类的)来决定对应在程序中对象的关系.
即程序中的对象都是数据库结构的对应,然后再使用Transaction Script的方式来调用.
这带来的好处就是简单,容易.不用太多的考虑OO的概念,也不会有太多复杂的Logic (因为是小的系统嘛.)
坏处也是不言而喻的.没有Practise太多OO式的开发,对于复杂的Logic就显得心有余而力不足了.
在Java中,数据库只是用来存储数据的.但是现在主流的db还是结构化的,不是面向对象的DB.所以于对java程序员而言,过多的考虑数据的存储结构以及数据的读写,是一件很恼火的事.
Java程序员说,我要有一个解脱的工具,于是,便有了O/RM.
解放出来的程序员们,可以更加Focus在对象模型的建立上面了,更加专注Design Pattern方面的建设了.
现在, .NET把 O/R M 也引入了.但是因为一开始的设计模型就不是一样的,所以不是太习惯于 O/RM的使用,在某些用法上面是和Java中的 O/RM是”背道而驰”的,并不符合M$给大家带来的思维方式.
基于这种理由/假设,M$取消了曾经Plan中的 ObjectSpace, 转而向 DLinQ了.继续M$在.NET开发中的领导位置 
