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

 

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

 

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

 

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

 

 

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

 

 

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

 

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

 

 

 

 

 

 

 

 

 

   

评论

51 楼 windshome 2013-06-06  

10年都不敢说精通的事情很多，因为世界在发展，技术也在发展变化，又不能像纯粹的技术研究人员那样去研究，只有在实际开发中去运用和理解。


我也同意你的要求对产品有更好的可控性这个说法，但是通常时候，很多技术都有从不认识，到逐步了解，到掌握，到可控这个过程。所以很多时候，即便不能完全掌控，不能非常精通，也还是可以在项目中使用的。

你说的JDBC，又有多少人能完全精通和掌控呢？我估计即便用JDBC2-3年的，也不大敢这么说。我也用JDBC时间很长了，感觉自己对这个东西也只有一知半解。自嘲一下，呵呵。

50 楼 rensanning 2013-06-06  

houxinyou 写道

rola 写道

各位，有考虑过维护吗?前几天，单位的一个使用了8年的Sybase库要迁移到Oracle，使用的是Hibernate，结果还是比较容易的？
说ORM不好的，大都是不怎么了解的，都是人云亦云。Hibernate现在我用了10年了，也不敢说完全精通，只不过依据个人的设计能力和项目复杂度，选用合适的技术和框架。
我想问的是，各位真的了解【面向对象】吗？如果真的吃透了，怎么会在ORM和JDBC上摇摆不定呢？

你用了十年都不敢说完全精通,一项技术用了十年都不能完全掌握,那么这个技术我真不敢用,还用JDBC好了,至少用过一段时间就能掌握.对于不可控的东西,学习可以,但是真的要用,还是算了吧

这位朋友过于偏激了。“掌握”“不可控”“精通”这几个词的含义是不一样的。“精通”这个词在国内目前处于被滥用的状态。“闻道有先后,术业有专攻”，不是所有中国人都能“精通”汉语吧！

49 楼 houxinyou 2013-06-06  

rola 写道

各位，有考虑过维护吗?前几天，单位的一个使用了8年的Sybase库要迁移到Oracle，使用的是Hibernate，结果还是比较容易的？
说ORM不好的，大都是不怎么了解的，都是人云亦云。Hibernate现在我用了10年了，也不敢说完全精通，只不过依据个人的设计能力和项目复杂度，选用合适的技术和框架。
我想问的是，各位真的了解【面向对象】吗？如果真的吃透了，怎么会在ORM和JDBC上摇摆不定呢？

你用了十年都不敢说完全精通,一项技术用了十年都不能完全掌握,那么这个技术我真不敢用,还用JDBC好了,至少用过一段时间就能掌握.对于不可控的东西,学习可以,但是真的要用,还是算了吧

48 楼 dwangel 2013-05-31  

windshome 写道

对 dwangel 回复一声：其实效率是考虑的一个重点。开发的效率固然也重要，但是在我的场景里，一个产品，从第一个版本V1.0开始设计和研发，往往2.X才能真正推向市场，面对客户，所以和产品质量、对设计和代码的掌控，比开发速度重要。

我说的就是这个意思啊。

看项目需求来的。

47 楼 windshome 2013-05-31  

其实我这篇文章的本意就是在做产品的时候，摒弃速食主义这种做法，也不要有为了节省点时间和代码量寻找免费午餐这种想法。在某些特殊项目不可避免，但是，对于一个需要长时间打造雕琢、长期改进更新的产品，最好是自己的技术选型，审慎考虑。

并不是说ORM怎么不好，只是被很多人用不好的方式使用，很多时候看得太重要。

以我的经验来讲，系统的复杂度，只能系统分析设计人员去面对，分析和解决，依靠通用性的框架和API是不大现实的。他们能解决的，是通用层面的问题。

想劝一下几位回帖的兄弟，讨论技术问题嘛，别生气也别上火。因为每个人都只能根据所知道的，所熟悉的，来得出临时的结论，用这样的结论来指导自己面对新的事物、新的领域，不断修正和完善自己的临时性结论。也许，技术生涯，都在这样不断的改进完善中度过。所以，我不怕自己浅薄，把自己的一些技术方面的想法说出来，一是能得到大家的指教，甚有幸焉；二则有助于自己心态变得成熟，不固守自己的技术知识和经验。


我常常笑自己是井底之蛙、夏虫不可语冰，所以尽可能使技术的讨论和辩论不演变成意气之争。别人说得对也好，不对也好，都欢迎提出对我的看法，哪怕是讥嘲也可以，但是讥嘲的话得让我明白，自己是哪里不足的，好改进过来。


对 dwangel 回复一声：其实效率是考虑的一个重点。开发的效率固然也重要，但是在我的场景里，一个产品，从第一个版本V1.0开始设计和研发，往往2.X才能真正推向市场，面对客户，所以和产品质量、对设计和代码的掌控，比开发速度重要。

46 楼 dwangel 2013-05-31  

windshome 写道

我做的系统不多，呵呵，也就几个吧，但是都是亿级数据量，365*7*24不间断运行的，承载关键业务的。而且，每个产品都会要求兼容Oracle、DB2、SQLServer、Sybase数据库，甚至还要对每一种数据库尽量发挥最大的效率和存取能力。

我的意思是不管怎么迁移，JDBC和ORM基本上所面临的工作都是一样的。

关注点不同。
你做的系统关注运行效率。

但是有些项目的注重的是开发效率，或者需求经常变更，业务需求变更的需求大于运行性能需求了，这时候，通过ORM，减少一些重复代码的编写就可以减少很多开发成本。

不过，在业务需求相对固定之后，hibernate可以改成直接访问存储过程模式了。
那时，就不能简单地改映射文件就能完成数据结构变更，要改相应的各种文件……

45 楼 damoqiongqiu 2013-05-31  

@archy123 这帖子不是我的，就不在这儿骂你了，免得影响人楼主。

44 楼 damoqiongqiu 2013-05-31  

archy123 写道

damoqiongqiu 写道

archy123 写道

damoqiongqiu 写道

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

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

你说【好像】说明你不确定，也就是说你自己并没有涉及过银行业务。
对于自己没有涉及过的领域，不要意气风发、指点江山，那不是技术人员应有的行事风格。
我一直做电信领域，对银行相关的业务不作评论。

无知者无畏！

多学习，什么都不懂的时候不要出来乱说  

43 楼 archy123 2013-05-31  

damoqiongqiu 写道

archy123 写道

damoqiongqiu 写道

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

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

你说【好像】说明你不确定，也就是说你自己并没有涉及过银行业务。
对于自己没有涉及过的领域，不要意气风发、指点江山，那不是技术人员应有的行事风格。
我一直做电信领域，对银行相关的业务不作评论。

无知者无畏！

42 楼 damoqiongqiu 2013-05-31  

archy123 写道

damoqiongqiu 写道

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

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

你说【好像】说明你不确定，也就是说你自己并没有涉及过银行业务。
对于自己没有涉及过的领域，不要意气风发、指点江山，那不是技术人员应有的行事风格。
我一直做电信领域，对银行相关的业务不作评论。

41 楼 windshome 2013-05-30  

我做的系统不多，呵呵，也就几个吧，但是都是亿级数据量，365*7*24不间断运行的，承载关键业务的。而且，每个产品都会要求兼容Oracle、DB2、SQLServer、Sybase数据库，甚至还要对每一种数据库尽量发挥最大的效率和存取能力。

我的意思是不管怎么迁移，JDBC和ORM基本上所面临的工作都是一样的。

40 楼 Tyrion 2013-05-30  

snowolf 写道

看来做的系统不大，不曾遇到很多迁移系统。这方面半自动化的iBatis比Hibernate更灵活。orm主要是减少事务处理，代码开发量工作，并且保证质量。多做一些系统之后再来看这个问题，感觉博主接触的时间还太短。

呵呵，刚想说对于遗留系统的改造这个事，你说出来了。

39 楼 snowolf 2013-05-30  

看来做的系统不大，不曾遇到很多迁移系统。这方面半自动化的iBatis比Hibernate更灵活。orm主要是减少事务处理，代码开发量工作，并且保证质量。多做一些系统之后再来看这个问题，感觉博主接触的时间还太短。

38 楼 windshome 2013-05-30  

嗯，我的意见就是到Library就够了，不要再成为FrameWork了。

37 楼 rensanning 2013-05-30  

到底采用“全自动”的Hibernate，还是“半自动”的iBATIS/MyBatis，或者严格意义上不能成为ORM的Apache Commons DbUtils，主要在于想让他帮你做什么。Martin Fowler 在 Inversion Of Control 一文中有如下论述：

引用

Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.

A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points.

假设不采用ORM，从API入手封装自己的DAO处理，考虑到开发效率、可移植性、可维护性、可扩展性，你的代码也未必能逃过以下发展过程。
API → Toolkit → Libarary → Framework

问题不在于选择Toolkit还是Libarary或者Framework，而在于对象模型的建设。

36 楼 windshome 2013-05-30  

rola 写道

各位，有考虑过维护吗?前几天，单位的一个使用了8年的Sybase库要迁移到Oracle，使用的是Hibernate，结果还是比较容易的？
说ORM不好的，大都是不怎么了解的，都是人云亦云。Hibernate现在我用了10年了，也不敢说完全精通，只不过依据个人的设计能力和项目复杂度，选用合适的技术和框架。
我想问的是，各位真的了解【面向对象】吗？如果真的吃透了，怎么会在ORM和JDBC上摇摆不定呢？

设计的好的话，数据迁移和维护应该是不困难的啊。主要是需求和设计阶段搞得好才行，不是后期的实现的问题。

我曾经做过大概6-7千万数据从DB2迁至sybase，旧系统只支持DB2，新版本的系统支持DB2/Oracle/Sybase/SQLServer，需求和架构做得好，经过仔细的分析和测试，最后实施一切顺畅--当然，我使用的是JDBC。

35 楼 须等待 2013-05-30  

rola 写道

各位，有考虑过维护吗?前几天，单位的一个使用了8年的Sybase库要迁移到Oracle，使用的是Hibernate，结果还是比较容易的？
说ORM不好的，大都是不怎么了解的，都是人云亦云。Hibernate现在我用了10年了，也不敢说完全精通，只不过依据个人的设计能力和项目复杂度，选用合适的技术和框架。
我想问的是，各位真的了解【面向对象】吗？如果真的吃透了，怎么会在ORM和JDBC上摇摆不定呢？

这我就不敢苟同了，ORM是面向对象难道JDBC就不是面向对象？ORM还不是JDBC封装出来的？
真正的大师一样能用JDBC封装出良好的程序，一样能应付变更的需求。

还是那句话，每一种框架和技术都有其存在的道理，有其对应的业务场景，只有客观的了解了它的特点才能在特定的业务场景使用最正确的解决方案

34 楼 rola 2013-05-30  

各位，有考虑过维护吗?前几天，单位的一个使用了8年的Sybase库要迁移到Oracle，使用的是Hibernate，结果还是比较容易的？
说ORM不好的，大都是不怎么了解的，都是人云亦云。Hibernate现在我用了10年了，也不敢说完全精通，只不过依据个人的设计能力和项目复杂度，选用合适的技术和框架。
我想问的是，各位真的了解【面向对象】吗？如果真的吃透了，怎么会在ORM和JDBC上摇摆不定呢？

33 楼 Tyrion 2013-05-30  

以前看《领域驱动设计》这本书时，就一直想做项目能够像楼主这么搞，可以完全集中精力于业务层。但是这么几年下来，从来没达到过这样的状态。

32 楼 sundoctor 2013-05-29  

我也认同业务设计，可是现在公司都是倒过来的，上来就数据库设计，一个业务一张表，而且这还是需求人员设计数据库，公司高层认可这样的开发模式，晕死了