O/R Mapping再乱弹

Posted on 2006-06-09 20:46 hbifts 阅读(2606) 评论(20) 编辑收藏网摘所属分类: .NET

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开发中的领导位置

Feedback

#1楼  回复 引用 查看

2006-06-09 21:07 by idior

@hbifts
谈的有点乱啊，前面谈的是分布式啊和持久层没什么关系啊。
MS在企业级应用的失败确实和之前的在分布式方面没有J2ee来的标准有关，但是和O/R m没啥关系啊。

MS主张数据驱动跟他是数据库厂商可能也不无关系。

#2楼  回复 引用

2006-06-09 21:11 by robinz-hbifts[未注册用户]

我不觉得M$的失败是因为没有J2EE的标准啊..
这个标准不是一下子就可以制订好的.
得是有经验才行的.

M$刚开始那里会有这样的经验呢? Java领域也不是Java一产生就有J2EE的.
这需要一个过程哇...

#3楼  回复 引用 查看

2006-06-09 21:18 by idior

但Ms那时确实是失败了，你认为他失败在哪呢？
我理解企业式应用无非就是数据存储和分布式这两个大头。

不过在web services这个分布式技术上, MS倒是打了一个翻身仗，看目前的WSE和WCF的发展，在SOA来临时，.net在企业市场这块确实大有希望。不过对于IBM和BEA那边的发展情况我不是很了解。

还有DLINQ这项技术我个人感觉十分危险，很容易导致滥用。懂的人，用的好了那是不错，但是不懂的人很容易陷入数据库的泥潭里。当然这可能是因为我对他了解的不是很深。

#4楼  回复 引用

2006-06-09 21:29 by robinz-hbifts[未注册用户]

M$当时的失败在于没有把握住Internet.

在以前M$平台上面的开发中,一直是使用Rick Client,也就是Windows的桌面为主的.但是Internet的到来,迅速的发展,B/S结构的推行,使得M$如意算盘全打翻了.(可以再回想一下当时Bill说过的"一切都是NET,下一个操作系统就是Windows.NET").

再加上以前Windows的网络应用开发成本比较高,C/C++学习曲线不够平滑,Win32 API的使用成本也不底.........

同意M$现在来看,在未来的企业市场,是可以有很大的作为的.

#5楼  回复 引用

2006-06-09 21:38 by robinz-hbifts[未注册用户]

LingQ,我觉得就是M$在维护它的"以DB为中心"的开发模型...

让你从以前的开发模型转向实际的code模型,让你越来越习惯于结构化查询似的方式.

等到某一天,有人问,"你还记得NHibernate吗",你答,"啊? 什么东西啊? 那个什么 O/RM的东西吗? 他有什么好用的.我不要OO,我只要结构化查询,写代码和写SQL一样简单.多爽啊~~~".

呵呵.

#6楼  回复 引用 查看

2006-06-09 22:32 by 双鱼座

@robinz-hbifts
我晕倒...SQL简单么?实现一个Action的确是很简单，但是维护、测试、扩展、伸缩，简单么？
另外，在企业应用上，MS从来不承认Java却又开发了不伦不类的J++，开发了虚拟机却不承认是JRE。直到.net出现、C#出现，才有了Java真正的对手。(以上文字来自Cay S. Horstmann的Core Java一书)。C#吸收了导致Java成功的精华，所以势头渐强。三年前我曾断言Java将死于C#。一年后，我发现我大错特错。一个成功者最大的包袱就是他的成功。Java如此，所以发展总是赶不上C#，拿一个G#就轻松解决AspectJ这种吃力不讨好的AOP实现；再拿一个LinQ就解决了OO的查询。
可是回过头来，MS就没有包袱么？MS有大量的桌面用户群。这些用户群往往不如J2EE用户群的价值高，却数量巨大，众口难调，就没有了Java世界的单纯。这个世界根本找不到任何包治百病的良药，Java的O/R Mapping如此,.Net的DataSet也是如此。

#7楼  回复 引用 查看

2006-06-09 23:40 by 蔡克伦

以我有限的ORM使用经验来看，我觉得纯粹的O->R或者R->O在实际应用中都是不太现实的，在设计一个系统时肯定是领域模型和数据库方案要同时考虑。因为如果纯粹的O->R的话，那R就完全去符合O的需要，为O服务，这样设计出来的数据库结构其他系统如何去使用？如何做系统集成？毕竟数据是企业的核心内容；纯粹R->O也不行，那样做的话领域模型在设计时受到的束缚就太多了，必然会有很多不够合理的设计。

ps：还是用win32api写程序有成就感啊，现在用.net再也没有那种感觉了，很多东西已经不能自己去控制了。

#8楼  回复 引用

2006-06-10 00:06 by robinz-hbifts[未注册用户]

我觉得在使用java的那一套的时候,你就不应该去过多的考虑数据怎么存储的.
存储的方案是什么样的?

你只需要把Business Logic中的Domain Object找出来,然后交给Hibernate或是EntityBean,由它们去负责把数据放到db中...

这也是为什么O/R Mapping在Java里面那么火.

在.NET里面,一切以DB为中心,从DB Schame开始设计,导致Transaction Script的Pattern的流行,使得NHibernate没能取得像Hibernate在Java中的影响...

#9楼  回复 引用

2006-06-10 00:28 by werwe[未注册用户]

http://music.k3265.cn

#10楼  回复 引用 查看

2006-06-10 00:40 by idior

因为如果纯粹的O->R的话，那R就完全去符合O的需要，为O服务，这样设计出来的数据库结构其他系统如何去使用？如何做系统集成？毕竟数据是企业的核心内容；

这种观念已经过时了。
一个系统最重要的不是他的数据而是他所提供的服务。通过数据库来实现集成是复杂且不现实的方法，通过服务通过消息来实现系统和系统的交互才更合理，也更加得容易实现。这也是SOA之所以火热得原因。

#11楼  回复 引用

2006-06-10 02:13 by robinz-hbifts[未注册用户]

数据是企业的核心吗?
那Business Logic怎么办? 算什么?
没有特定的Business Logic,Data有意义吗?

所以上面的
"因为如果纯粹的O->R的话，那R就完全去符合O的需要，为O服务，这样设计出来的数据库结构其他系统如何去使用？如何做系统集成？毕竟数据是企业的核心内容；"
说法是有靠不住的.

Idior说的很对,只有数据和特定的Business Logic集成在一块后,才是有价值的.

#12楼  回复 引用 查看

2006-06-10 08:56 by 蔡克伦

@idior
@robinz-hbifts
我说的“数据是企业的核心”是下面的意思：
　　比如我们实现一套财务系统，使用纯粹O->R的方案，于是我们关心的是领域模型，数据库的结构没人关心，他只要能够为O服务，满足O的需求就可以了。三四年后，由于用户单位规模的扩大，原来的系统已经不能满足需要了，或者Java已经8.0了，.NET已经4.0了，新的虚拟机效率大大的提高了，这时候用户决定废弃原有的系统，用新技术再实现一套系统，可能还会增加一些新的需求。这时候以前三四年的财务数据难道都不要了吗？如果当初没有对数据库结构的充分重视，那么数据库的结构对于新的开发组来说将是混乱的，完全不可理解的，这时候不要说在原有数据库结构上搭建新的系统，就算新的开发组自己重新设计数据库结构，然后把老数据导过来，也是极端困难的。（请考虑数据库表在200张以上的情况）

#13楼  回复 引用 查看

2006-06-10 11:12 by idior

@蔡克伦
Java已经8.0了，.NET已经4.0了，新的虚拟机效率大大的提高了，就因为这个你要抛弃老的系统？现实吗？
应该是为了新的功能集成现有的系统才更符合实际，这个时候仍然可以通过SOA的思想来解决，现在这个年代性能不是最重要的，不然不会有SOA的产生。
SOA其中重要的一点就是对业务逻辑的复用。

#14楼  回复 引用 查看

2006-06-10 12:07 by 蔡克伦

@idior
好，就算新的开发技术带来的效率提高可以忽略，那么如果是因为用户数量的剧增，而导致以前的系统不能承受了（假设以前的系统不是物理分布式的），现在需要一套分布式的系统，而且业务也有一些增加，这时候选择重新开发一套系统未必就不是不可能的，而且这种情况我以前就碰到过。
你说的SOA来解决，怎么解决？原来的系统我已经不用了，难道要先在原系统中增加需要的SOA入口，然后新的系统通过这个接口来间接的访问原来的业务数据？我觉得这样做才不现实啊。

其实我是举双手支持领域模型，支持OO的。但就我想说的是也不要完全忽略了数据库的设计，大多数情况下客户数据库里保存的数据才是最值钱的东西，你一套Java还是.NET的系统相对来说简直太便宜了。

#15楼  回复 引用

2006-06-10 12:59 by kw2006[未注册用户]

@蔡克伦
@idior
觉得你们两个说的都有道理，没有本质的矛盾，侧重点不同而已。
如果你今天面临的一个项目是把一个 client (vb/vc++/delphi etc)+ DB 的企业级应用，改写/升级到 .NET 时代，但所有历史数据都要保留，而且要在一段时间内保证两个系统都能同时运行，可能你也会有蔡克伦同学的感慨。如果今天开始设计一个系统，那肯定是 O 先 R 后。但是在有老系统需要兼顾的时候，只能看具体需求来 balance 了，我以为。
本来想 google 一个时间表出来，来看看那些产品/技术的出生日，成长的里程碑，来证明微软也没有“输掉”某场战役，Java 也没有错失良机，结果发现微软确实应该在推行 Windows DNA 时，就把 model driven 的概念引入并加以实现。
不过如果真的是那样，生活多没有悬念啊，太不丰富多彩了。