ORM已经死了吗？我不喜欢ORM这东西

 

       做开发这一行这么多年，Java开发也十多年了，我一直不大喜欢ORM这个东西，我觉得这个东西实际上是对思路的一种误导，这也和常见ORM的做法有关。

 

      我做系统设计时，一般都是先不设计数据库，或是把数据库设计尽可能后延，先把系统业务逻辑中，各种对象的业务关系，使用UML、流程图或伪码、代码的方式来描述，来评审，而其中数据存取部分都是伪实现和伪设计，在设计期间，只要描述说，可以将业务对象保存起来，可以将某个业务对象取出来就可以。这样，完全抛开了数据库对业务设计的干扰。

 

    在我系统设计的观念里，没有所谓“实体对象”和“控制对象”这个词，只有“业务对象”，后期实现业务对象的持久化，我基本上都完全推到实现和编码阶段。我的看法，在早期的设计阶段，必须完全以业务对象和业务逻辑为主，不应该分心去想别的。所谓“实体对象”和“控制对象”对业务是无意义的。

 

 

在JDon上看到一个经典的说法：

 

 

事实上，在数据的访问上，我们需要的，仅仅是一个小小的库， 帮助我们完成连接的管理和结果集数据的自动提取而已。

 

当然，更为严重的是那句“ORM已死”，呵呵，我倒没有想ORM是否死了，我只是简单的认为，ORM根本就是系统中的一个小工具层，不应当称为“框架”。我们更不能让这些东西干扰我们的设计。设计以体现业务的过程为主。

 

 

 

 

 

 

 

 

 

   

评论

31 楼 diggywang 2013-05-29  

超级复杂的，是很难用上ORM！
超级简单的，不稀罕用ORM！
只有不大不小的，拿ORM当工具，可以节省些时间。
现有系统很多个关键业务，存储过程在Oracle Exadata上一跑就是好几个小时，sql代码都在2万行以上，这种场景用ORM，估计要吐血...

30 楼 windshome 2013-05-29  

islove1945 写道

用不用orm如何影响业务逻辑层的设计，真想不出为什么。觉得应该是数据库表的逻辑设计影响到后台业务逻辑的设计吧，你在dao里用什么方法持久化数据应该不会对业务逻辑造成影响，在getXXX，saveXXX些方法里可以自由选择认为合适的方法去access数据库。
orm的oo操作数据库方式，hiberante的缓存机制，对osgi和jbpm的支持都是选择他得原因，至于缺点呢也不少，要具体去权衡用不用了。

我是指目前对ORM的不当使用来讲的，当然你用的好，不会有什么坏的影响，还能给开发带来好处，那是自然的事情。从表结构产生代码，从类产生数据库结构，这两种典型的不好的实践。都有一个特点：省时间。为了省时间，就是速食主义的做法，是做产品的忌讳，也是我最反对的（项目不在讨论之列）。

还是请看我后一篇解释 http://windshome.iteye.com/blog/1879212

29 楼 islove1945 2013-05-29  

用不用orm如何影响业务逻辑层的设计，真想不出为什么。觉得应该是数据库表的逻辑设计影响到后台业务逻辑的设计吧，你在dao里用什么方法持久化数据应该不会对业务逻辑造成影响，在getXXX，saveXXX些方法里可以自由选择认为合适的方法去access数据库。
orm的oo操作数据库方式，hiberante的缓存机制，对osgi和jbpm的支持都是选择他得原因，至于缺点呢也不少，要具体去权衡用不用了。

28 楼 white_crucifix 2013-05-29  

楼主你可以点击别人用户名右边那个“引用”超链及，在回帖框里会自动生成引用格式的～ 哈哈

27 楼 windshome 2013-05-29  

回复 guilipan ，我还是有一次从JDon上看到对象和关系数据库“阻抗”这一说法，觉得很新奇。我从来不认为这两者之间有什么阻抗。

当然，两者不是一个时代的概念，自然，区别很大。但是也完全可以通过“数据”这一中间层在产品项目中合作无间。无非是对象->数据->数据库。这是很简单的思路，实现起来也不复杂。


当然，要是非不想用中间的“数据”，就一门心思把对象直接塞到数据库中，那自然有各种设计上的问题了。

26 楼 windshome 2013-05-29  

须等待 写道

windshome 写道

银行业务分很多种，例如核心、网上银行、企业应用等等，性质不同，采用的技术也不同。

童鞋你对银行业务很熟悉啊，我想跳去银行，有什么comments吗？

前些年和银行客户打交道很多，顺道了解了不少信息而已。目前的工作和银行关系不大。

有个建议，就是如果要跳到银行，一定去小行，不要去大行。小行例如浦发、民生都非常好；大行，例如工行、农行待遇一般，而且辛苦。

25 楼 须等待 2013-05-29  

windshome 写道

银行业务分很多种，例如核心、网上银行、企业应用等等，性质不同，采用的技术也不同。

童鞋你对银行业务很熟悉啊，我想跳去银行，有什么comments吗？

24 楼 guilipan 2013-05-29  

ORM的出现是解决数据库模型和后台语言中的模型(类)的阻抗失调,这也是为什么现在有领域驱动开发出现,很多工具的出现都只是在众多限制条件下的trade-off

23 楼 windshome 2013-05-29  

银行业务分很多种，例如核心、网上银行、企业应用等等，性质不同，采用的技术也不同。

22 楼 archy123 2013-05-29  

damoqiongqiu 写道

回楼上，就不引用了。
【映射】这个东西一定是存在的，只要想存库，必然存在【映射】
从【映射】的角度看，自己写SQL插表叫映射；用所谓的ORM框架协助插表，也叫映射
原文重点不在于否定【映射】这个动作，重点在于是否需要所谓的ORM【框架】
我的观点和原作者基本一致
【只有小系统才有可能用所谓的“全自动ORM框架”，复杂业务系统，所谓“自动化的ORM”根本用不起来，或者使用的成本太高，比直接JDBC+一些辅助工具例如DBUtil要高太多（不举例，有兴趣可以直接找我私下交流）】

好像很多银行系统使用的就是hibernate，不知道银行系统业务算不算复杂

21 楼 windshome 2013-05-29  

其实我想表达的是：从设计上说，只有业务对象。和业务对象的行为、业务对象之间的关联。

20 楼 white_crucifix 2013-05-29  

其实不太清楚楼主的“业务对象”和“实体对象”区别。因为从原则上来说，orm框架，比如hibernate，只会对系统设计的进行延伸，应该不会干扰系统设计。比如楼主说的设计时只到存储层之上的，那么在编码期，orm做的就是将你设计的最终的对象给映射到database里。
当然这是理论上的，因为现实的系统往往需求复杂多变，就是上层产生的一个对象不是简单的就映射到db里的一张或两张表。这里就涉及到orm框架一个讨论更为广泛的话题，就是需求复杂的时候，用orm框架合算吗，有时候直接写sql甚至效率更好，包括编程效率和执行性能。

19 楼 windshome 2013-05-29  

兼听则明，我肯定不会固守自己的意见，不管什么样的意见，只要都是对于技术的讨论和思考，都欢迎大家提出，都表示欢迎，哪怕观点和我南辕北辙。

18 楼 damoqiongqiu 2013-05-29  

楼主没必要理睬无聊的人，那种人无法静下心来倾听别人意见，没什么前途的

17 楼 windshome 2013-05-29  

nfoliver ，我可没有那个意思，我只是说我不喜欢而已。并不强加这个观点给别人。而且本身把这个写在文章里，也是想和大家沟通，希望得到高手的指点和指正。根据项目本身特点决定技术选型那是必然的。

16 楼 nfoliver 2013-05-29  

你不喜欢就得死？你能决定的了？我觉得还是要根据项目本身去决定！

15 楼 alvin198761 2013-05-29  

只怪你们做的东西都跟数据库有关，不做这方面的，啥事没有，

14 楼 damoqiongqiu 2013-05-29  

回楼上，就不引用了。
【映射】这个东西一定是存在的，只要想存库，必然存在【映射】
从【映射】的角度看，自己写SQL插表叫映射；用所谓的ORM框架协助插表，也叫映射
原文重点不在于否定【映射】这个动作，重点在于是否需要所谓的ORM【框架】
我的观点和原作者基本一致
【只有小系统才有可能用所谓的“全自动ORM框架”，复杂业务系统，所谓“自动化的ORM”根本用不起来，或者使用的成本太高，比直接JDBC+一些辅助工具例如DBUtil要高太多（不举例，有兴趣可以直接找我私下交流）】

13 楼 jinnianshilongnian 2013-05-29  

LeoChowComtop 写道

damoqiongqiu 写道

实体关系映射本来就是个伪概念
在业务非常复杂的系统里面，程序里面的【实体】，或者说业务对象，本身结构非常复杂，而且实体之间的关系很复杂，而且多变。很少能简单配置配置就映射成关系型数据里面的记录。
能很简单地进行映射的表很少，比如静态表、域表之类的

你说的我挺认同，ORM当工具使嘛，这玩意不万能，所以ibatis才有生存空间咩，还有的全存储过程开发的。

其实只要对象-关系之间无法直接转换，就会有映射器；
如hibernate是全自动的映射器（SQL、设值都是自动的）
如ibatis是半自动的映射器（SQL要手工、设值按照规则自动的）
如spring jdbc也是自动/半自动的（SQL要手工、设值可自动/手动）
还有如jdbc完成手动；
就看怎么选的问题了；都有存在的意义。

12 楼 LeoChowComtop 2013-05-29  

damoqiongqiu 写道

实体关系映射本来就是个伪概念
在业务非常复杂的系统里面，程序里面的【实体】，或者说业务对象，本身结构非常复杂，而且实体之间的关系很复杂，而且多变。很少能简单配置配置就映射成关系型数据里面的记录。
能很简单地进行映射的表很少，比如静态表、域表之类的

你说的我挺认同，ORM当工具使嘛，这玩意不万能，所以ibatis才有生存空间咩，还有的全存储过程开发的。