高手谈ORM之硬伤.docVIP

实用标准文案 精彩文档 高手谈HYPERLINK /Barton131420/archive/2007/01/07/613955.htmlORM之硬伤 前言 我是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外, 没有任何的存储过程.  HYPERLINK /Barton131420/archive/2007/01/07/613955.htmlORM之硬伤 园子里有些人，他们真以为自己明白了面向对象，然后装着满腹经纶，侃侃而谈，一篇接一篇，不厌其烦地喊着ORM如何如何。你以为他真的明白“面向对象”么？其实，他对面向对象的理解仅限于教科书中的封装、继承和多态，或者再知道一点面向对象的若干原则但其实并不真正理解。 笔者愚钝，入行多年尚不懂面向对象，只懂得用其形而不懂用其实。五年后的某一天终于开窍，明白了面向对象之实，也仅仅是一个开始而已。当又经历了另一个五年的倦怠，发现并理解了设计模式、面向方面等技术作为面向对象的必要补充后，才算是彻悟！所以当我见过一个同学，尚未出校门已然彻悟，真是羞愧！ 有一天面试的时候，我问一位同学，Framework和Library的区别是什么？他答不上来。而另一个同学略一思考就告诉我，你的程序会调用Library，而Framework会调用你的程序。虽然精辟，但我还是要补充：Framework通常也会提供一个Library，所以，Library是水平的，而Framework是垂直的，此处的“水平”和“垂直”是相对应用系统的层次设计而言的。如果没有层次，其实Framework其实就是Library。Microsoft的Enterprise Library当然就是一个Library，无法代替Framework。 如果让那位已经彻悟的同学舍弃ORM来实现复杂的业务功能，他当然无法接受。相反，如果让一位抱着《Thinking in Java》似懂非懂的同学用ORM来实现同样的功能，他也一样无法接受。其中的一些同学非常擅于“鸡蛋里挑骨头”，于是园子里有了这样一堆垃圾文章或者垃圾跟贴。另外一些同学不精于这样的能力，所以仍在徬徨之中。 此乃ORM惟一之硬伤也！如果你不理解面向对象思想，就先试着去理解，然后再来讨论ORM这个话题，并发表你的高见。 再说性能 ORM提供了所有SQL语句的生成，代码人员远离了数据库概念。从一个概念需求(例如一个HQL)映射为一个SQL语句，并不需要什么代价，连1%的性能损失都没有。真正的性能损失在映射过程中，更具体地讲，是在对象实例化的过程中。我曾经做过一个试验，以“计算第N个素数”这样的命题。我采用Delphi写Native Win32 Console程序，又采用C#写CLR Console程序。两者相比，令我大失所望。 N 结果 耗时 Delphi C# 1000 7927 0ms 2ms 10000 104743 16ms 17ms 100000 1299721 438ms 324ms 1000000 15485