对ORM的讨论，兼回复几位朋友

 

        我觉得ITEye的回复管理不好用，或者是我用不好这个功能，所以如果回复内容较多的时候，还是单独写一篇吧。

 

       首先要说的是 jinnianshilongnian你老兄太客气了，你觉得我的说法不对就直说，归根到底，我们只能根据已有的经验，说一说自己的看法，对不对，都需要多听取别人的看法，来完善自己的认识，所以说欢迎大家的指教，这是帮助我成长，改正我错误的观念。

     一般我认为，因为系统复杂，所以要“挫其锐，解其纷”进行复杂度分解，分解之后的每一个部分，都不会还是盘根错节，那么复杂了。当然，这只是我遇到的情况。

     我赞成你的“对业务对象建模”这一说法，根据业务的需求和逻辑，分析业务对象和业务对象的各种行为、交互，是系统需求分析和设计阶段最重要的事情。我的说法，这个时候不要把数据库和ORM这东西引入进来；甚至说，连想这方面的事情都不去想。

 

    你对框架和工具的理解我完全赞成。在进行产品开发时，有时候会选择一些框架（可能是选择外部开源的框架例如Spring等等，还有可能在开发组内部一些人开发自用的框架-----几年前我就是主导框架部分开发的，所以对框架和工具之间的区别比较清楚，呵呵，见笑）；有可能会选择一些工具，例如Google的Guava、JDK的并发包、Apache的Common等等。

  

   我自己从事框架的设计开发以及产品设计时，有一个感触，所以催生了更愿意把ORM当成“工具”而不是“框架”，就是因为框架和工具的这个区别，选好框架后，自己做具体实现，挂到框架中，你要跟着框架的思路来走；工具是随你自己需要提供低一层的功能，思路是由自己主导的。框架从快速开发的角度，非常有利于快速开发（针对一些时间紧的项目是这样最好），但是对需要长期不断完善、改进、精雕细琢的产品来讲，第一个版本的开发，只是万里长征的第一步，所以这时候开发的速度并不是最重要的。

 

   有点跑题了，说回ORM，我的业务层的业务对象之间的逻辑关系都已经设计和实现好了，只是对象->数据库和从数据库里取出来制定的业务对象还没有实现，这时候，我需要一个工具，能够按要求把这些功能给实现了，如此而已。所以，从这个角度我说ORM最好只是一个工具。就像上篇文章里引用的文字的说法。

 

       说到你提出的ORM干扰设计这个说法，其实我上篇文章表达的不好，并不是说ORM这东西本身怎么不好，干扰什么设计，而是很多人，只是为了自己省一些代码工作量，为了有一些“免费的午餐”，对ORM这东西的滥用，对设计造成了干扰。

 

       我觉得对产品设计来讲，先设计数据库，然后从数据库表产生代码就是一种不好的设计和开发实践，造成了OOD的过程从设计数据库表结构开始；先设计对象，再通过注解产生数据库表结构呢，的确要好很多，看上去OO了，但实际上，大多数时候不能很好的利用数据库的特性，因为我经历过很多项目和产品，数据库的设计，客户要求一定要和他们的DBA协商确定的，根据自身的业务对稳定性、性能和维护方便的要求来设计的，不可能由产品开发设计人员完全确定。

 

    你说的很对，要根据情境选择合适的工具。一般来讲，选择之前，先应该摒弃“省点代码，省点时间”和“找点免费的午餐”这些想法，再来选择或设计自己的技术路线和工具、框架。

 

 

对 dwangel 的回复

 

      楼主做的系统不够多，涉及的数据类型没有达到一定的数量级。

 

 

的确，我做的系统不够多，但是我做的系统也是在客户那里7*24*365运转，每天承载全国的业务；涉及系统数据类型没有达到一定的数量级，这是工作特点决定的，所以我的确有井底之蛙的嫌疑，我也愿意大家把自己的经验讲给我，让我增长见识。

 

还是那句话，系统在设计时，应该先进行子系统分解，然后是模块分解，如果分解了很久，每个模块还是异常复杂，数据类型、业务流程和业务对象之间的关系还是那么复杂，那么我觉得业务的分解过程做得不是很好。架构设计的一个重要任务，就是把系统的复杂度分解到各个子系统和模块，每个子系统和模块都承担一部分复杂度，再协作完成系统的工作目标。你分解了半天，每个子系统和模块还异常复杂（甚至涉及的数据类型还都是成千上万的，是不是有问题

 

      而且不是大团队作业。

 

    团队作业又怎么样呢？大的团队，上百人一起工作，其实也无非是分割成一个个小团队来做，甚至小团队内部再划分成几个组来进行工作。团队建建立起良好的工作（设计和编码等）规范和制度来降低沟通的成本，或者建立星形的沟通结果，避免网状沟通。这一点是人的问题和管理的问题，和任何技术选型都是无关的。

 

  当然，框架本身的确包含了一定的设计规范在其中，这是无可非议的。

 

   你说的业务对象建模没有问题，只是此“业务对象”是和数据库无关的，跟ORM更无关。在使用业务对象搭建系统完成之后再来使用ORM其实也是很好的。

 

回复Allen：

 

    我没有这个意思，我很讨厌把业务逻辑放在数据库里。别人怎么设计我不管，我设计系统时，业务逻辑一定要放在程序代码中。这篇东西本身就是为了表达自己对ORM的看法，以及对“ORM已死”这个说法的一些思考。