>
返回专题首页
阅读排行
· ORM之硬伤 (18408)
· 设计架构优秀的 Framework - 兼谈 ORM Framework (15539)
· 关于ORM和内存数据库的遐想 (14371)
· 从我的亲身经历来说说我对ORM的一些看法 (13739)
· 只有企业级项目才特别需要使用ORM (11478)
· 扬长避短，适度使用ORM. (11185)
· 大型软件开发与ORM构架 (10669)
最新评论
>
re: ORM之硬伤
呵呵 今天又看到这篇老帖子
我目前还比较倾向于dataaccess class+代码生成器的架构
- WhyCome[at]live.cn 2008-03-27 21:15
>
re: ORM之硬伤
很多人还是不懂OO的，我就是一个，哈哈！
- 猫非猫 2007-11-14 15:11
>
re: 关于ORM和内存数据库的遐想
看你的网页眼睛好累！
也许黑底可以省电，或看起来很酷，但文章内容请不要使用白色的字，用黄色或其它柔和些的颜色会好些！
- 朋友 2007-08-25 12:26
>
re: 关于ORM和内存数据库的遐想
我感觉还有可行的，只是在部署的时候麻烦一些，但只要系统内部写的严谨，对一些突发事件考虑的很细致，效率上可以提高不少，还是值得去用的，但大家是否考虑在很多数据并发的时候怎么处理？还不是要频繁的去读取？还不如直接。。。把硬盘全换成闪盘，呵呵！
- 土星的狗狗 2007-07-24 16:33
>
re: 关于ORM和内存数据库的遐想[未登录]
内存数据库,很好的想法,不过这东西实施起来有一定的难度
- acheqi 2007-07-18 09:19
>
re: 关于ORM和内存数据库的遐想
韩国有个内存数据库 在 深圳高新技术展展出的了。湖南电信买了的
我估计不怎么好 。东西都在内存 万一死了 那不就 爽歪歪了。
- 嘻嘻 2007-07-16 16:30
>
re: ORM之硬伤
"从一个概念需求(例如一个HQL)映射为一个SQL语句，并不需要什么代价，连1%的性能损失都没有。真正的性能损失在映射过程中，更具体地讲，是在对象实例化的过程中"
我觉得所说的性能损失这只是一方面,另一面问题就在于"从一个概念需求(例如一个HQL)映射为一个SQL语句",SQL语句对程序员来说是不可控的,也就是说程序员无法优化SQL,而系统效率的影响往往都在跟数据库打交道上
- Sephil 2007-06-08 15:43
>
博客是好东西[未登录]
博客是好东西
- 我 2007-05-27 18:42
>
re: 扬长避短，适度使用ORM.
@ukyoxh
同意。低风险。
现在的ORM还好了，主要是适度。
- 随心所欲 2007-05-11 15:04
>
re: 扬长避短，适度使用ORM.
其实对于企业应用最重要的还是低风险
使用了一段时间的IBATIS后发现和TransactionScope一起使用的时候会报错，所以放弃使用了，因为有的时候方便是方便，但是如果万一产生一些风险却承受不起，个人看法！！
- ukyoxh 2007-05-11 14:51
>
re: 从我的亲身经历来说说我对ORM的一些看法
最近怎么看到这么多关于ORM的文章。
看来很多人闲着没事。
- 周鹏 2007-05-03 03:22
>
re: ORM之硬伤
不用ORM，同样能实现OO，ORM的思想很好，接收这个思想就可以了。
用不用倒不是重要问题
- 周鹏 2007-05-03 03:15
>
re: ORM之硬伤
底层的东西一般会带来性能的好处, 你用说DataSet比ORM性能好, 那我说C++, 汇编会有更好的性能. 你说SQL会比映射性能好, 那我说OCI会有更好的性能.
其实性能问题, 很多人耿耿于怀. 我们应该这样来看性能问题, 性能最终要从需求, 实现系统的代价来综合考虑.
我认为比如对于典型的数据保存操作, 用户可以接受的响应时间是3妙. 只要不大于3秒就是可以的. 你说你用0.00001秒的时间就实现了, 速度是快了很多很多倍, 其实是无用的, 但有人就是看重这些东西, 我也就无话可说了
- 昆仑居士 2007-04-21 09:44
>
re: ORM之硬伤
@阿水
我是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外, 没有任何的存储过程.
- 昆仑居士 2007-04-21 09:30
>
re: ORM之硬伤
@阿水
我非常同意你的观点。 很多大型的项目，业务逻辑是相当复杂的。
- Shark Xu 2007-04-17 10:44
>
re: 关于ORM和内存数据库的遐想
好
- 域名注册 2007-04-02 15:36
>
re: ORM之硬伤
楼主：你可以贴出一个你认为最好的ORM代码。比个例子：就是举入库单的例子吧。（注意：是支持分仓的）。
谢谢！
- DaiWei 2007-03-20 18:36
>
re: ORM之硬伤
@DaiWei
同意你的一部分解释。我所理解的远离DB并不是说开发人员完全不了解DB，而是在开发过程中不受DB的控制。我不认为面向对象数据库可以取代所谓的ORM，因为两者的功能不同，工作的层面也不同。我现在都不明白面向对象的DB将来如何做BI。
我可以打一个不够恰当的比喻：很多人开发asp.net应用的时候，根本不了解http协议以及不同的web容器的不同实现，但是他们不是也一样写的很好？原因就是有非常好的web框架封装了http协议的过程，实质上也就让开发者远离了http。当然，如果开发者能够完全掌握了http协议并且也了解当前的web容器对http的实现，我想就更好了。
- 双鱼座 2007-03-20 11:29
>
re: ORM之硬伤
不同意楼主的观点。
我们的业务对象是面向对象的，我们的关系型数据库是面向关系的，对于这二者之间如果顺畅的进行通信？我个人不太赞同用ORM这样的工具去完成，理由很简单，它太笨重。而且，据楼主说，使用ORM的最主要的好处是：让开发人员远离DB，而我却很难想象，在企业级的应用程序开发中，一个开发人员不懂关系DB，是一个什么概念。
或许等面向对象的数据库成熟了，这些争论就没有了吧。
- DaiWei 2007-03-20 10:52
>
re: ORM之硬伤
Sql语言用熟了的话，它的很多功能是非常方便的（当然可能是我对ORM工具不够熟才有此一言）。
现在还是哪个技术更熟悉就用哪个，反正Linq也快出来了。
不用ORM的话，用个Code Generator也是不错的，当然手写也行。
不管黑猫白猫，抓到老鼠就是好猫。
- deerchao 2007-03-14 12:09