回味那些评论有时候也能受教－－摘自双鱼座ROM之硬件评论

# re: ORM之硬伤 2007-01-07 12:38 fds2003

精辟！！受教！！  回复  更多评论   

# re: ORM之硬伤 2007-01-07 12:57 kiler

说的太好了。
很好批驳一些人对orm的质疑。
  回复  更多评论   

# re: ORM之硬伤 2007-01-07 12:58 Jeffrey Zhao

非常同意一些观点，还有一些尚在体会之中。  回复  更多评论   

# re: ORM之硬伤 2007-01-07 13:24 iceboundrock

其实.net的ORM还有个伤，就是，.net社群还没有一个象java社群的hibernate那样的，有重大影响力和广泛应用的ORM框架。不过迟早会有的。

以前做java的时候，spring和hibernate用起来的感觉真是非常的爽。
.net的nhibernate和spring.net，感觉总是不对。  回复  更多评论   

# re: ORM之硬伤 2007-01-07 13:25 小新0574

不错，不过从面向对象去谈ORM说得好少，也没有从架构角度去谈  回复  更多评论   

# re: ORM之硬伤 2007-01-07 13:55 枫

很不错，文中的内容让我对ORM又有了一些新的认识。

"所以，如果你完全依赖Hibernate去持久化，我非常担心你将来是否有机会用你的数据积累去做数据仓库。"

很赞同，我本来也想在我的文章里提到的，但由于不是很了解这方面所以就略过了。不过我对你框架中的数据库的ER以及面向对象的关联和聚合的协调部分很有兴趣，不知道能否赐教一二。  回复  更多评论   

# re: ORM之硬伤 2007-01-07 13:59 Zhongkeruanjian

ORM也有自己的适用范围，并不是所有的系统都得用ORM。就像面向对象的语言的产生是为了解决越拉越庞大的软件系统的复杂性，扩展性和复用性。而基于操作系统的软件（驱动等）它肯定不适合一样。ORM也不能解决所有的问题。它有它自己的适用范围。

即使是这样，在一个非常适合于ORM的系统里，也必须考虑很多问题，举个例子：
我们都知道ORM是将数据库的记录映射成实体，它不会像SQL那样可以灵活的取某一，两个字段（当然ORM也可以，比如NH中的投影映射，不过这是相当的别扭）。那么我们在作设计时，必须要避免某些情况，比如，数据库的列的内容要尽量的少，我曾经见过有人将数据库某个表中加了个IMAGE字段，而几乎每行都有IMAGE的存储，少则1，2M，多则10M，而这个字段几乎很少在业务逻辑中用到（附件），然后抱怨ORM性能太差。这时候，你就必须考虑将image放在文件系统中，而在数据库中存个路径就OK。（当然，HIBERNATE有某一字段的延迟加载，NET这边还没有这个功能，即便是这样，也不是万能的，比如在Remoting系统里，延迟加载统统失效）。  回复  更多评论   

# re: ORM之硬伤 2007-01-07 14:10 Teddy's Knowledge Base

精炼！几乎找不出论证过程中的任何破绽！

orm思想永远没错，但现实的项目情况，往往不是论证中的那么完美。可能是使用orm的程序员的个人能力问题；也有可能是，项目必须基于db到oo，不允许再从oo到db；或者构架师选择了一个不像“kanas”那么完美的orm实现，或者，程序员对于所用的orm组件的使用不熟悉，等等等等都有可能让项目陷入困境。那么谁来救救这些项目？

和任何新技术新思想一样，orm在解决了很多问题同时，也不可避免会带来新的问题和新的成本。很多时候大家作选择时，不完全是（甚至更大程度上不是）出于技术本身的优劣、或者优雅，而是出于成本。

最后一个大家都十分关心问题：.net 2.0的kanas本月能按时发布吗？  回复  更多评论   

# re: ORM之硬伤 2007-01-07 14:12 midea0978

至今还没有看到一个大型的成功的MIS系统架构在 ORM之上的，往往是一些很小的WEB应用成了某些狂热爱好者的试验田。楼主做过几个成功的ORM项目呢
oracle 11i、sap如果也是用的ORM，就服了。

就像很多人叫UML怎么好，结果整出来文档的给用户看是一抹黑，通常也只是在打单的时候宣称，真正项目开始时，不了了之，用得好的少得很。

很多人会说，你不懂，懂得人少就用不起来，是认识的问题，但是一个东西这么难认识的时候，也就只能是停留在纸面讨论了。

你看struts，这么简单实用，哪个项目都看得到影子，这种框架才叫好的框架，EJB，有几个人用好了？  回复  更多评论   

# re: ORM之硬伤 2007-01-07 14:28 阿水

ORM 的宗旨就是OO来解决业务规则问题，但是关系数据库
已经存在很多年，很多基于DB的技术都很成熟，个人认为
ORM只是 为了OO而使用的妥协折中的方法，绝对不是 什么
了不起 也不是必须用的东西
如果 你处理过很多复杂业务规则，多层游标 大概就知道我的意思
我曾经试图把一个很复杂的 存储过程 用OO的方式 实现
姑且不论 性能问题 首先并发就要命 而且 实现起来 几乎到
后来 就写不下去了 需要 大概 10几个类 每个类都有 很多方法
可是 原来用存储过程 也就 400 多行 当然 我最后没有完成
因为感觉 实在 没有必要 个人感觉ORM 使用与 团队中
的人 大多不熟悉复杂SQL的项目 如果 团队里人都很
熟悉 SQL 个人看不出 ORM的好处
另外个人觉得 很多社区里 倡导ORM的有各 误区
总是 认为ORM 是主要实现 持久化的
其实ORM 主要是 OO的方式 处理业务规则的
数据持久化 本就不是什么复杂的东西 用不用ORM
区别不大 就是不用ORM也一样 能 提高开发效率 而且不一定
比用ORM 效率低 我是说用DATASET，DATATABLE
可是 用ORM进行业务规则 最大的考虑就是业务架构
可是 有多少 大项目的 架构师 真正能 设计出 合理的架构呢
本人 的能力 经过几次尝试 发现 确实不行
因为 对 业务规则OO 需要定义很多 CLASS 多得让你
头皮发麻
后来 发现还是SQL搞定算了，毕竟大家都很多熟悉SQL
哈哈 本人 以前从事 商业零售 行业的软件 现在
作WMS 呵呵
欢迎大家一起讨论。
  回复  更多评论   

# re: ORM之硬伤 2007-01-07 15:22 木野狐

好文，学习了。  回复  更多评论   

# re: ORM之硬伤 2007-01-07 15:36 Hunts.C

Mark下，等我了解了ORM的始终 再来拜读：）  回复  更多评论   

# re: ORM之硬伤 2007-01-07 15:37 麒麟.NET

文章很精辟，很受益，感谢作者的付出！

阿水兄，你觉得是类更容易调试维护，还是存储过程？

400行的存储过程，这已经让人头皮发麻了。。。  回复  更多评论   

# re: ORM之硬伤 2007-01-07 16:17 kiler

@阿水

要哪个菜鸟在看你的存储过程的时候不小心手抖了一下加了点东西，那就够你受的了。
  回复  更多评论   

# re: ORM之硬伤 2007-01-07 16:28 空明流转

首先声明我是个菜鸟。我个人感觉就是，用什么都是跟着设计走的，ORM为我们处理业务和数据提供了一条现成的桥梁，至于用不用，完全在于开发团队和项目的需要。

从诸位牛们的讨论情况来看，ORM有价值，是无可厚非的。那么既然是一个有价值的工具，又不是强迫你使用的，何必要贬低或者抬高它呢。  回复  更多评论   

# re: ORM之硬伤 2007-01-07 18:27 idior

精彩！
.net社区（包括博客园）不理解面向对象的人实在太多！请这些人好好修炼，不要在首页“叫嚣乎东西，隳突乎南北”。搞得我现在在首页看到这个话题就想闪。  回复  更多评论   

# re: ORM之硬伤 2007-01-07 19:16 阿水

400行的存储过程确实比较难维护，这个我必须承认，至于调试，我觉得区别不大，存储过程一样可以调试。
To kiler 我说过，一个团队都不熟悉SQL确实ORM不错，但是如果一个团队都
很熟悉SQL，我觉得问题不大，同样你弄一堆类。也未见得一个菜鸟就可以搞定。

当然储存过程比较难维护向比较与同样代码量的类来讲。这里需要澄清一点是，
写存储过程并不是乱写，怎么晦涩怎么写，其实存储过程也是软件开发的一部分（在过去相当长的一段时间以及现在）存储过程一样要求，有合理的设计，规划，分类，注释，文档 而不简单的就是一堆没有人能看懂的SQL。这里要说的是，架构，设计，这些东西不是在OO之后才有，以前就有，OO只是给设计增加了一种 很好的方法论。

to idior呵呵不知老兄 不理解面向对象的人实在太多 是否包含在下。首先我不是一个科学家，不是专家，也不是老师，不是研究者。我需要做的合理的解决我所面临的问题，OO只是一种方法论，不能解决所有问题。如果老兄觉得自己OO的造诣确实很好，可以自己设计一个系统试一下。规模也就100张数据表（不是按OO的方式划分表，而是以DB的方式）ORM能解决一下问题，但绝对不是什么人，什么规模的系统都适合。
  回复  更多评论   

# 转 ORM之硬伤 [TrackBack] 2007-01-07 19:19 JYun

原贴http://www.cnblogs.com/Barton131420/archive/2007/01/07/613955.html园子里有些人，他们真以为自己明白了面向对象，然后装着满腹经纶，...  查看原文  回复  更多评论   

# re: ORM之硬伤 2007-01-07 20:24 idior

@阿水
我没有特指任何人。
当java社区广泛讨论的话题已是如何建立种种框架、工具，从而充分发挥oo优势的背景下。
.net的社区还有不少人认为oo是一种高级的方法论，是科学家，专家，老师或研究者才应该掌握的技术。我们已经可以发现其中的差距了。
  回复  更多评论   

# re: ORM之硬伤 2007-01-07 21:00 木野狐

呵呵，讨论归讨论，我觉得大家都在一个社区里混，应该具有包容的心，能够容纳各种水平的作者、文章。要知道每个人的发展都是由新手逐步成长的。
多一点理解和包容，社区会发展的更和谐：）  回复  更多评论   

# re: ORM之硬伤 2007-01-07 21:10 牧野

我觉得Teddy说得更为有理，客户需求是时刻变化的，DB结构是现成的，你也不能改，SP封装一部分业务逻辑在实际项目很有必要，OLTP用用ORM也还将就，OLAP的情况下，数据量如果到N个GB级或者TB级或者更高，如果还坚持ORM就会死得很难看，对于高层来讲,每天清晨开会时及时的看到Report永远比什么都重要

ORM对于我来讲，最大的问题是动态生成的SQL总是不会如事先预料的那样使用索引，一般是Table scan,或者Index scan,但在查询分析器中执行这段Sql又可以是Index seek,总是要在性能瓶颈处绕过ORM来调用SP,很是难受，不知谁有遇到过这种情况？

  回复  更多评论   

# re: ORM之硬伤 2007-01-07 22:12 idior

@木野狐
同意，我认错。就是忍不住喊了一把。  回复  更多评论   

# re: ORM之硬伤 2007-01-07 22:14 西门子乌

现在我终于知道为什么.Net程序员普遍比Java程序员工资要低了。就是因为不懂OO，自己还不求上进。ORM也能返回部分属性，如NHibernate中，我可以用HQL，select A.Name, A.Score from Student A，只不过返回的是IList，其中元素是object[]而已。  回复  更多评论   

# re: ORM之硬伤 2007-01-07 22:28 木野狐

hehe, 响应中央号召，共建和谐社会 :D  回复  更多评论   

# re: ORM之硬伤 2007-01-07 22:30 木野狐

@西门子乌
也许这一点 Visual Studio 也有责任，IDE 做的比较方便会惯坏很多程序员。
我感觉当初的 Delphi 就是这样，虽然其中也有极少数 Delphi 高手自己觉悟了。  回复  更多评论   

# re: ORM之硬伤 2007-01-07 23:13 neoragex2002

@西门子乌
千人一面、定势的思维方式才是做.net阵容比java阵容不值钱的原因。软件!=OO，OO也不算什么silver bullet，该用则用，用不着自欺欺人想得太高深，徒虚度时间而已.  回复  更多评论   

# re: ORM之硬伤 2007-01-08 00:30 Boler Guo

@木野狐 说的很好，社区就应该能使得各种不同阶段的开发人员共同前进~  回复  更多评论   

# re: ORM之硬伤 2007-01-08 02:03 sharewind

我是菜鸟，学习………………………………
  回复  更多评论   

# re: ORM之硬伤 2007-01-08 08:28 henry

错不在模式(是很多前辈总结出来的,是对是错我们先试问一下自己有没这个能力去评价)!
即使在代码编写过程使用了继承和多态也不代表代码就是好的,面对怎样的情况对代码进行重构和改进是每个开发人员必须要做的,如果什么都不做即使套用了最好的模式到最后可能只会变成一种负担．当产生反效果时有很多人就产生抱怨．  回复  更多评论   

# re: ORM之硬伤 2007-01-08 08:45 北风

很精彩且有力的文章！学习！
支持木野狐的观点，多一点包容的心，其实很多的人只是想把自己的理解说出来，错了能被人指正就是最终的目的。
ORM没有错，我的理解是可以规范程序员面向对象的开发，剥离SQL这个关注点。
Hibernate真的是不错，不过不知道NHibernate也可以达到同样的高度。  回复  更多评论   

# re: ORM之硬伤 2007-01-08 09:11 西门子乌

@neoragex2002
自辱之，人必辱之。
我也是做.Net的，对Java也略知皮毛。现在做.Net的动不动就DataSet，DataTable，要不就Sql满天飞，你算过维护成本吗？你考虑过复用吗？Java形式的后台服务＋.Net的界面才是硬道理。  回复  更多评论   

# re: ORM之硬伤 2007-01-08 09:21 风云

@木野狐
说的好,非常支持!  回复  更多评论   

# re: ORM之硬伤 2007-01-08 09:36 阿水

首先说声道歉，感觉自己有点激动了情绪有点失控，上面的兄弟们，如有开罪的地方还请多多包涵。

ORM的目的就是尽量的让开发人员，开不到DB，而看到的都是CLASS，从而能够用OO的方式来实现
业务规则（个人认为基本数据的持久化，随便怎么处理都不是问题），这里个人不赞同把ORM或者
OO说的很深奥，好像高不可攀的样子。毕竟我们的的目的是解决问题，如果OO的方式好，那么我们
就OO，而不是说所有问题一定要OO。其实现在仍然有很多领域的开发，根本不涉及OO，但是他们同
样也有设计，架构。另外个人有个问题一直想和大家讨论。做MIS系统的项目（不是产品研发）OO
到底能给我们带来多少便利，个人始终没有一个答案，虽然也苦思冥想了很久。这个也是我们始终
没有OO（用OO的方式来实现业务规则）的原因。希望通过在这里的讨论，能对我和大家都有所帮助。  回复  更多评论   

# re: ORM之硬伤 2007-01-08 09:46 补丁

不全同意
首先我们应该看到ORM的用意
然后我们看到ORM的优势
但是在我们试图探究ORM缺点的时候
是不是把ORM的某些确实做的不尽如人意的地方归咎到别处,就OK了呢?  回复  更多评论   

# re: ORM之硬伤 2007-01-08 09:50 小陆

@阿水
oo和面向过程分道扬镳的位置不是在编码，而是在需求分析的时候。oo把需求看作是一个个对象的交互，而面向过程把需求看作是一条条流程的交织。
因此象你这样用class重写存储过程的行为，以及对着数据库表再来设计对象模型的行为，可以看作费力不讨好的傻事。你是在把oo代码生硬的嫁接在面向过程的分析上。
这也就是现实，在大部分人把需求看作流程的情况下，oo的作用目前仅限于UI＋DAO，ORM自然也就退化成数据库访问组件。ORM作为数据库访问组件其实并不好用。  回复  更多评论   

# re: ORM之硬伤 2007-01-08 10:09 阿水

TO 小陆
在大部分人把需求看作流程的情况下，oo的作用目前仅限于UI＋DAO，ORM自然也就退化成数据库访问组件。ORM作为数据库访问组件其实并不好用。
这句话，非常赞同。
本人功力一般，也试图OO的方式分析，涉及系统。实话说在我们作的这行业
的MIS OO分析真的很累，因为设计太多的CLASS，当然也可能是我们没有
掌握正确的方法。
TO 补丁
很欣赏你的观点，ORM确实有它好的地方，但缺点也不少，如果说
ORM真如楼主说的那样，我想OO的数据库根本就没有存在发展的必要，
事实上不是这样。  回复  更多评论   

# re: ORM之硬伤 2007-01-08 10:27 Cure

不要试图让ORM是万能的，不要试图用ORM取作他本不应作的事。一些所谓ORM的缺点实际上是我们试图用他取解决他不擅长的问题，而在这些领域，有很多更好的方案。  回复  更多评论   

# re: ORM之硬伤 2007-01-08 10:58 hj821111

收藏..  回复  更多评论   

# re: ORM之硬伤 2007-01-08 11:06 kiler

@小陆

对“ORM作为数据库访问组件其实并不好用”这句话不是很理解。
能详细说一下吗？

我觉得ORM访问数据库挺方便的，至少比用存储过程和sql强。
  回复  更多评论   

# re: ORM之硬伤 2007-01-08 11:11 kiler

@Cure

在.net开发这一块，orm不是被滥用了，而是基本上没什么人用。
倒是很多人在滥用数据库的功能去完成一些他本不应作的事，例如用存储过程去处理业务逻辑。  回复  更多评论   

# re: ORM之硬伤 2007-01-08 11:33 双鱼座

@ALL
非常感谢各位对本文的关注!大家的真知灼见令我受教!

@Zhongkeruanjian
我其实很想听你详细讲讲"适用范围"。通常我们将软件分为系统软件和应用软件，系统软件当然是永远用不着ORM的。

@Teddy's Knowledge Base
你有些过奖了。其实任何技术都有风险，但是这些风险如果不是ORM所特有的就不适合专门提出来。
新版本如在本月提交出来，但这个版本可能仅仅只是中间版本，也就是有一些设计的目标可能不会全部实现。当然，性能方面我会有一个专门的测试报告。

@midea0978
你所看到的不一定是全部，当然我看到的也不一定是全部。Hibernate已经成为JavaEE的规范，还能说ORM仅仅是“试验田”么？

@idior
大侠言之凿凿，OO的确需要修炼，当然每个人的修炼经历可能不完全相同，基本的经历应该有What、How、Why、Why Not、How Not几个过程。很多人还仅仅停留在What阶段。

@牧野
有道理。所以既然是框架就必然会提供用户扩展，而Library是不需要用户扩展的。  回复  更多评论   

# re: ORM之硬伤 2007-01-08 11:45 小陆

@kiler
你认为拿hib当个数据库访问组件好用吗。用tomcat（可能是spring吧，管他呢）自带的连接池我只要把对应的jdbc jar复制到lib目录里面，再在xml配置里面写上一个连接字符串，就ok了。
用hib那个东西，光是一堆配置文件就足够把很多菜鸟吓晕过去。老鸟有足够的本事来摆平这些配置，但是毕竟是很麻烦的事情。
“并且使用起来是多么的不习惯啊，原本只要写一个sql条件就可以了，现在要在一堆对象里面找来找去。”
对于满脑子数据库的人来说，他最需要的是记录集，没有数据集他是很不安的，他不知道他的程序还能做什么。于是他完全是在把orm当作数据访问组件来用，把DAO当作记录集来用。这就造成了他们的系统用了orm比不用orm更加复杂，加班不断，维护痛苦。自然他们就反对这个东西。

@阿水
MIS也许是最适宜使用orm的一类了，对于很多人来说，只有一种情况能使他们不在MIS中考虑使用orm：需要顾忌旧系统的维护情况。
我可以总结一个基本的情况：凡是用户是人的系统（比如MIS、ERP），面向对象比面向过程简单；凡是用户是机器的系统（比如伽马刀的控制、交换机的话单采集），面向过程比面向对象简单。  回复  更多评论   

# re: ORM之硬伤 2007-01-08 13:33 阿水

哈哈 讨论了很多了来一个 业务吧，也是我们项目中实际的功能。
一个医药配送中心管理系统。中有这样一个业务（客户提出，设计时没有）
仓库里的药品损益不直接修改库存，而是到另一个库存里（异常库存）
比如 报损10 那么 异常库存里就是-10 ，报益为正数。
现在 说异常库存里 有很多记录，有正有负。现在的要求是
把商品编号相同，但是批号不同的记录。数量能够正负抵消的
记录，生成一张单据。单据明细记录格式如下
编号 批号 数量
a 1 10
a 2 -10
......
希望大家能，给与我一些指导。我当时写这个功能
用PLSQL 写了 230行，声明了3个游标。  回复  更多评论   

# re: ORM之硬伤 2007-01-08 14:36 kiler

@阿水
select * from [异常库存] where [编号] in (select [编号] from (select [编号],Sum([数量]) as [总量] from [异常库存]) where [总量]=0) order by [编号] ,[批号]

就是一个按编号分组查询统计 数量字段的总数， 数量总数为0的挑出来。  回复  更多评论   

# re: ORM之硬伤 2007-01-08 16:07 幸运草

ORM 有它的好处同样也有他的优势，SQL也同样有他的优势，项目也是因人而异，我更喜欢 在项目中ORM 和SQL共存，偶是菜鸟  回复  更多评论   

# re: ORM之硬伤 2007-01-08 16:13 幸运草

假如一个小的网站根本就没有维护代码的必要，你还会去ORM吗？几条SQL就能解决的问题，这就有点用“大炮打蚊子”。假如是一套进销存有维护的价值和进一步开发的必要那就要好好的ORM一下，否则漫天的SQL会让你找不到北。个人关点。再次声明偶是菜鸟。  回复  更多评论   

# re: ORM之硬伤 2007-01-08 16:42 随心所欲

说的非常好。

orm是一个工具，他由他的特点，至于是优点还是缺点，这得看你怎么样他，用在什么地方。  回复  更多评论   

# re: ORM之硬伤 2007-01-08 17:20 阿水

TO kiler
赫赫 挑出来了 需要处理的商品编号,但是还需要 一个商品一个商品的处理,而且处理没一个商品的时候.还要把其正负相抵的数据取出来.
另外 你那个SQL最好不要用IN 这个效率不好。
换成exists 或者JOIN效率会好一些。

可能是我前面没说清楚。如果 A 10 A-5 两条记录 同样要抵消
处理完之后 是 A 5 赫赫 这个问题可能不是很恰当
不过还是感谢你的回复。
  回复  更多评论   

# re: ORM之硬伤 2007-01-08 17:27 neoragex2002

@西门子乌
我无意侮辱任何人，如果你认为我说的是你，那只能说明你正好是我说的那一类人。不必再抬什么成本、复用出来了，耳朵起茧了。就这样吧，各人有各人的观点，走好自己的路就行。  回复  更多评论   

# re: ORM之硬伤 2007-01-08 17:54 meil

其实没有好坏之分的，都是工具就看适不适用。
就像救火，自家小火，泼几桶水就OK了，如果没有及时发现酿成火灾，就要打119了，如果报告晚了，谁也救不了。
我们这得电视塔（塔中部的餐厅）有一年着火了，连消防队都没折就看着它烧完。因为着火点离地面太远没有工具
  回复  更多评论   

# re: ORM之硬伤 2007-01-09 11:34 midea0978

**引用** "不理解面向对象的人实在太多！请这些人好好修炼"

说上面这样话的人，建议不要说话，随便给人戴帽子的人不适合的！！

讨论到现在的地步，感觉已经比较真实了，作为一种方法论的探讨是不错，但是不切实际的往现实解决方案中套也是不对的，在面向企业MIS的解决方案中，往往最现实、最好用、贴合实际的才是最好的，不一定要ORM、OOP、UML、Hibernate。。。，也可以做得很好，这才是最重要的。

我看过的一个平台，delphi开发的客户端，服务段JAVA+(RESIN/weblogic)+STRUTS+ACTION+BO+DAO(SQL语句，实现ins,del,update等)，数据库Oracle,SQl Server,当然包括存储过程，通讯协议为HTTP+XML数据包。主要做了企业的ERP制造系统、销售系统、物流系统、售后服务系统、供应链系统、PDM等，平台的思路简单、满足了客户端表现层的灵活性，兼顾了服务端的开放、扩展性。毕竟java的项目报价就高一些！
类似的平台见过2-3个，感觉不错，不知大家有什么思路可以探讨一下。  回复  更多评论   

# re: ORM之硬伤 2007-01-11 00:55 阿标

可能你拼命写出来的sql，跟nhibernate生成的差不了多少。
  回复  更多评论   

# re: ORM之硬伤 2007-03-14 12:09 deerchao

Sql语言用熟了的话，它的很多功能是非常方便的（当然可能是我对ORM工具不够熟才有此一言）。

现在还是哪个技术更熟悉就用哪个，反正Linq也快出来了。
不用ORM的话，用个Code Generator也是不错的，当然手写也行。

不管黑猫白猫，抓到老鼠就是好猫。  回复  更多评论   

# re: ORM之硬伤 2007-03-20 10:52 DaiWei

不同意楼主的观点。
我们的业务对象是面向对象的，我们的关系型数据库是面向关系的，对于这二者之间如果顺畅的进行通信？我个人不太赞同用ORM这样的工具去完成，理由很简单，它太笨重。而且，据楼主说，使用ORM的最主要的好处是：让开发人员远离DB，而我却很难想象，在企业级的应用程序开发中，一个开发人员不懂关系DB，是一个什么概念。

或许等面向对象的数据库成熟了，这些争论就没有了吧。  回复  更多评论   

# re: ORM之硬伤 2007-03-20 11:29 双鱼座

@DaiWei
同意你的一部分解释。我所理解的远离DB并不是说开发人员完全不了解DB，而是在开发过程中不受DB的控制。我不认为面向对象数据库可以取代所谓的ORM，因为两者的功能不同，工作的层面也不同。我现在都不明白面向对象的DB将来如何做BI。
我可以打一个不够恰当的比喻：很多人开发asp.net应用的时候，根本不了解http协议以及不同的web容器的不同实现，但是他们不是也一样写的很好？原因就是有非常好的web框架封装了http协议的过程，实质上也就让开发者远离了http。当然，如果开发者能够完全掌握了http协议并且也了解当前的web容器对http的实现，我想就更好了。  回复  更多评论   

# re: ORM之硬伤 2007-03-20 18:36 DaiWei

楼主：你可以贴出一个你认为最好的ORM代码。比个例子：就是举入库单的例子吧。（注意：是支持分仓的）。
谢谢！  回复  更多评论   

# re: ORM之硬伤 2007-04-17 10:44 Shark Xu

@阿水
我非常同意你的观点。 很多大型的项目，业务逻辑是相当复杂的。  回复  更多评论   

# re: ORM之硬伤 2007-04-21 09:30 昆仑居士

@阿水


我是Oracle, SqlServer 认证得DBA, 也曾在Oracle, sqlserver中写过100,000行以上的存储过程, 但现在已经彻底的转换到ORM上了, 现在已经用ORM成功开发了10个系统.
ORM的好处是抛弃了传统的面向过程的方法, 远离了数据库和SQL.使开发更多的使面向业务领域.
用Orm的系统, 如果配备适当的辅助工具, 比如代码生成, 会有极高的开发效率.
用ORM实现的系统, 会有极强的可维护性, 可以非常快的满足用户需要的变更, 这点实际上对开发来说, 是绝对重要的.



ORM带来的问题是大约有20%的性能损失, 其实性能的问题更多低是算法,框架和领域设计的问题.没必要从太底层方面去考虑.
还有就是ORM初期需要写的代码比常规要多很多. 而这些代码不一定马上就要用, 或可以更简单的写. 有些同志总是哪代码行数来说话, 认为用代码量少实现的系统就是优秀的系统. 实际上软件开发的质量评价标准从来就没有代码行这个指标. 关于代码量的问题, ORM必须配备辅助代码生成工具,不然就是一个硬伤.
ORM不能实现复杂的业务逻辑. 我看这个问题不成立. 比如Web开发时, 需要一些复杂的网格来表示数据, 我看见很多人就用输出html table来实现. 我用封装后的DataGrid一样的实现了,并且用更快的速度实现了.其实问题的关键是他们没有很好的掌握DataGrid的用法, 就只能用比较原始的办法了. 我用纯ORM成功的实现了一个物流管理平台. 其中这个平台有管理机构, 很多的货主, 很多的客户, 很多的运输机构, 很多的库存, 设计很多的运输方式, 货物运输的合并, 分坼. 业务相当的复杂. 除View外, 没有任何的存储过程.



  回复  更多评论   

# re: ORM之硬伤 2007-04-21 09:44 昆仑居士

底层的东西一般会带来性能的好处, 你用说DataSet比ORM性能好, 那我说C++, 汇编会有更好的性能. 你说SQL会比映射性能好, 那我说OCI会有更好的性能.
其实性能问题, 很多人耿耿于怀. 我们应该这样来看性能问题, 性能最终要从需求, 实现系统的代价来综合考虑.
我认为比如对于典型的数据保存操作, 用户可以接受的响应时间是3妙. 只要不大于3秒就是可以的. 你说你用0.00001秒的时间就实现了, 速度是快了很多很多倍, 其实是无用的, 但有人就是看重这些东西, 我也就无话可说了  回复  更多评论   

# re: ORM之硬伤 2007-05-03 03:15 周鹏

不用ORM，同样能实现OO，ORM的思想很好，接收这个思想就可以了。