对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已死”这个说法的一些思考。

 

 

 

 

 

 

评论

17 楼 mike.liu 2013-05-30  

To  truekbcl:

这个说法，是结构化设计的总结，现在有新的说法了。
--------
前面的我都理解，只是后面这句，不知道现在新的说法是什么，诚心讨教。

16 楼 truekbcl 2013-05-30  

mike.liu 写道

windshome 写道

欢迎mike.liu再次光顾我的文章，你的基础知识和功底比我丰富，向你学习。

我的意见是，你要表达数据结构，根本无需ORM。ORM的增删改查本身只是一种工具提供给上层的操作能力。具体的处理还得看业务。

很多的时候，ORM上是增删改查，而业务里边是另外的词汇，甚至，有很多业务要求，一个业务写多条数据，删除一些数据、修改一些数据，在一个事务里完成。这个时候，ORM里不掺和业务，只是提供一个操作数据的接口，上层业务流程组装这些东西。

关于业务和ORM的关系，我是这样理解的，欢迎批评指正：

程序=数据结构+算法

数据结构，在C里面就是struct，指针，数组等；在Java里面就是Bean，Object；在数据库里面，就是表结构，外键，关联表等。

业务其实是程序在另外一个层面的表述而已，所以每个业务必然包含数据和代码。

前辈大牛说，尽量把业务往数据里面塞，并提出以数据为中心进行程序设计，是因为这样设计出来的程序更健壮，更容易修改，更容易理解，更容易检查。

在Java企业级应用里面，最常用的数据就是Bean，Bean加上一些关系型的约束，就成为ORM，所以在企业级应用里面，把ORM与数据结构划等号，个人认为基本是没有什么问题的。如果这种理解没有错，那么就不能说ORM在业务分析和设计里面不重要。

当然在其它领域，比如桌面开发，可能对象直接在内存里面就可以了，大不了写到文件里面，这个时候是用不到什么ORM的。但是里面一样离不开数据。

------------
程序=数据结构+算法
2进制代码->汇编->结构化->多种范式，每个阶段有不同的总结。
这个说法，是结构化设计的总结，现在有新的说法了。

15 楼 truekbcl 2013-05-30  

windshome 写道

回复mike.liu：

关于   程序=数据结构+算法 这一说法，我专门写了一篇，也请光顾指正：
http://windshome.iteye.com/blog/1872031


数据结构是一个存在很久的东西了，ORM可能从某种程度上表现了数据结构，但是要想表达数据结构，完全可以和ORM无关。

其实我和老兄的观点的区别，在于我更倾向于从外部（业务、客户）的角度来去看待产品、软件和设计、程序；而你更倾向从内部（数据、算法、技术）。

《人月神话》作者Brooks说的好，软件开发中，最最困难的，本质的困难，就是需求规格，其实也就是业务的分析，我总是乐意从外部来看程序开发，也是基于这个理由，分析业务、描述业务如果清楚了，那么你的程序基本上就成功了一大半。

当然我并不是排斥工具，例如Ioc、ORM；只是想说，这些东西在产品开发中的位置和重要程度是不同的，作用也是不同的。

《人月神话》作者Brooks说的好，软件开发中，最最困难的，本质的困难，就是需求规格，其实也就是业务的分析，我总是乐意从外部来看程序开发，也是基于这个理由，分析业务、描述业务如果清楚了，那么你的程序基本上就成功了一大半。
----------------
这个只能是正确的废话。原因在于：任何领域的软件，你与使用者的理解可能都不相同，而且都可能没理解完整，而且还有N多的细节，需要解决的问题就是指数增长。这注定了“业务清楚”就是镜花水月。所以才会丢弃瀑布而采取敏捷。这个过程，不可能避免的。
另一方面，计算机语言也是一个问题。就oo的表达能力，实在是有点弱。所以造就了hibernate很难用。也造就了业务复杂了，代码的结构很难用。

14 楼 windshome 2013-05-30  

你说的这个我认可，我也的确打算看点RESTful方面资料，充实一下自己。但是我有一个信念，就是现在概念性的东西太多，感觉很繁杂。

总想着通用，结果就是哪里也不通，哪里都很费劲。

所谓CRUD，我认为就是对业务的一种抽象，抽象不是坏事，而是使用这种抽象方法的人，别忘了抽象的概念和具体的内容相结合，无论何时，还是以具体内容为主。


抽象的这个东西没有或者说抽象得不好也没什么大事，但是具体内容没有弄好，系统就失败了。我强调，更多去分析自己的具体业务，这不是简单的CRUD能涵盖的，把CRUD视为数据持久层的一种能力（相当于API）给上层用就可以了。

13 楼 mike.liu 2013-05-30  

另外，有一点感觉和楼主意见相同，就我目前所经历的看，的确是需求分析和设计这一阶段的工作做得很不够。从而导致整个项目的结果不理想。

但是这个仅仅是需求分析和设计的问题，与ORM无关。并且开发软件，始终是绕不过与ORM类似的底层框架、工具和平台的。迟早还是得用它们来表达所有的业务和设计。

12 楼 mike.liu 2013-05-30  

windshome 写道

mike.liu 写道

你的大作拜读了，以下是我的看法，供参考：

软件开发的过程，应该是从抽象到具体，从模糊到清晰的过程。

在前期，理解需求和分析业务阶段，不去考虑语言、框架，是应该的，必须的。我相信这一点和楼主意见一致。

但是无论如何，随着开发的逐步深入，所有需求分析出来的东西，都要具体化，也就是用什么语言、什么框架、什么数据结构、什么算法、什么数据库，甚至到用什么服务器，什么类型的CPU等等。即使你不做这个事情，也必定需要其他人来做这样的事情。即使不用ORM，也要有办法把数据结构持久化。

但是，如果一开始，就用ORM这样一类更严格的东西来描述表达业务需求，可以减少很多歧义，使业务理解达成共识更容易一些。如果客户无法理解ORM，也可以用他们能够理解的方式描述业务，然后总得有人把它翻译为ORM或者别的什么数据结构来表达。因为离开数据结构和算法，要做程序设计，至少以我的经验来看，还没有过。

退一步说，自然语言，每句话，里面也是有名词，有动词，有主语、谓语、宾语。都是可以映射到程序设计中的数据（结构）和算法的。而且也只有做了这种投射和翻译，计算机才有可能理解。凡是不能做这种投射的，计算机就不能理解。

所以ORM也好，数据结构也好，只是一个中间结果，用于帮助下一步以计算机能够理解的方式进行代码设计。

“程序就是用计算机能理解的方式，描述业务。”我理解的可能有点不一样，是这样的：业务是计算机能够理解的模拟现实世界的程序。

比如我提一个需求：设计一个可以像人类一样和我进行直接对话的机器。
你可以根据这个需求分解出很多业务，此时可以不管用什么语言、什么框架。但是到具体实现的时候，必定碰到怎么表达某个概念，数据以什么方式组织，怎么存储等等问题。如果做不到这些，那么就不能是业务。至少不是计算机能够实现的业务。

计算机无法实现的业务很多很多，包括中国特色的各种东西。

凡是计算机无法理解，不能执行的，都不能是业务。

其实我们没有多大的分歧，不同在于我想向设计开发人员强调业务需求，而老兄更在意设计开发过程。这本身就是一个大过程中的两个小过程。

我的文章本意是尽量减少ORM在设计过程的出现，其实目的在于针对目前ORM被滥用这一不好的现状。动辄Hibernate，动辄CRUD，我总觉得不好，当然也只是个人的感觉而已。

探讨使人进步。设计过程中是否尽量少出现ORM暂且不论，单就CRUD，推荐楼主去了解一下RESTful的风格的设计理念。即使不认同，也是他山之石。

程序设计中一个重要的步骤就是分解出业务中的名词性概念和动词性概念，如果在这种分解中，尽量把动词转换为动名词（比如：把“订购”转换为“订购记录”），则动词可以大大简化，简化到极致，就是CRUD。

另外，在需求分析和设计阶段，越早引入类似ORM这样的有严格定义、没有歧义的表达方式（前提是参与分析和设计的人都懂这个东西），就越能提高设计的质量和效率。

11 楼 windshome 2013-05-29  

mike.liu 写道

你的大作拜读了，以下是我的看法，供参考：

软件开发的过程，应该是从抽象到具体，从模糊到清晰的过程。

在前期，理解需求和分析业务阶段，不去考虑语言、框架，是应该的，必须的。我相信这一点和楼主意见一致。

但是无论如何，随着开发的逐步深入，所有需求分析出来的东西，都要具体化，也就是用什么语言、什么框架、什么数据结构、什么算法、什么数据库，甚至到用什么服务器，什么类型的CPU等等。即使你不做这个事情，也必定需要其他人来做这样的事情。即使不用ORM，也要有办法把数据结构持久化。

但是，如果一开始，就用ORM这样一类更严格的东西来描述表达业务需求，可以减少很多歧义，使业务理解达成共识更容易一些。如果客户无法理解ORM，也可以用他们能够理解的方式描述业务，然后总得有人把它翻译为ORM或者别的什么数据结构来表达。因为离开数据结构和算法，要做程序设计，至少以我的经验来看，还没有过。

退一步说，自然语言，每句话，里面也是有名词，有动词，有主语、谓语、宾语。都是可以映射到程序设计中的数据（结构）和算法的。而且也只有做了这种投射和翻译，计算机才有可能理解。凡是不能做这种投射的，计算机就不能理解。

所以ORM也好，数据结构也好，只是一个中间结果，用于帮助下一步以计算机能够理解的方式进行代码设计。

“程序就是用计算机能理解的方式，描述业务。”我理解的可能有点不一样，是这样的：业务是计算机能够理解的模拟现实世界的程序。

比如我提一个需求：设计一个可以像人类一样和我进行直接对话的机器。
你可以根据这个需求分解出很多业务，此时可以不管用什么语言、什么框架。但是到具体实现的时候，必定碰到怎么表达某个概念，数据以什么方式组织，怎么存储等等问题。如果做不到这些，那么就不能是业务。至少不是计算机能够实现的业务。

计算机无法实现的业务很多很多，包括中国特色的各种东西。

凡是计算机无法理解，不能执行的，都不能是业务。

其实我们没有多大的分歧，不同在于我想向设计开发人员强调业务需求，而老兄更在意设计开发过程。这本身就是一个大过程中的两个小过程。

我的文章本意是尽量减少ORM在设计过程的出现，其实目的在于针对目前ORM被滥用这一不好的现状。动辄Hibernate，动辄CRUD，我总觉得不好，当然也只是个人的感觉而已。

10 楼 mike.liu 2013-05-29  

你的大作拜读了，以下是我的看法，供参考：

软件开发的过程，应该是从抽象到具体，从模糊到清晰的过程。

在前期，理解需求和分析业务阶段，不去考虑语言、框架，是应该的，必须的。我相信这一点和楼主意见一致。

但是无论如何，随着开发的逐步深入，所有需求分析出来的东西，都要具体化，也就是用什么语言、什么框架、什么数据结构、什么算法、什么数据库，甚至到用什么服务器，什么类型的CPU等等。即使你不做这个事情，也必定需要其他人来做这样的事情。即使不用ORM，也要有办法把数据结构持久化。

但是，如果一开始，就用ORM这样一类更严格的东西来描述表达业务需求，可以减少很多歧义，使业务理解达成共识更容易一些。如果客户无法理解ORM，也可以用他们能够理解的方式描述业务，然后总得有人把它翻译为ORM或者别的什么数据结构来表达。因为离开数据结构和算法，要做程序设计，至少以我的经验来看，还没有过。

退一步说，自然语言，每句话，里面也是有名词，有动词，有主语、谓语、宾语。都是可以映射到程序设计中的数据（结构）和算法的。而且也只有做了这种投射和翻译，计算机才有可能理解。凡是不能做这种投射的，计算机就不能理解。

所以ORM也好，数据结构也好，只是一个中间结果，用于帮助下一步以计算机能够理解的方式进行代码设计。

“程序就是用计算机能理解的方式，描述业务。”我理解的可能有点不一样，是这样的：业务是计算机能够理解的模拟现实世界的程序。

比如我提一个需求：设计一个可以像人类一样和我进行直接对话的机器。
你可以根据这个需求分解出很多业务，此时可以不管用什么语言、什么框架。但是到具体实现的时候，必定碰到怎么表达某个概念，数据以什么方式组织，怎么存储等等问题。如果做不到这些，那么就不能是业务。至少不是计算机能够实现的业务。

计算机无法实现的业务很多很多，包括中国特色的各种东西。

凡是计算机无法理解，不能执行的，都不能是业务。

9 楼 windshome 2013-05-29  

回复mike.liu：

关于   程序=数据结构+算法 这一说法，我专门写了一篇，也请光顾指正：
http://windshome.iteye.com/blog/1872031


数据结构是一个存在很久的东西了，ORM可能从某种程度上表现了数据结构，但是要想表达数据结构，完全可以和ORM无关。

其实我和老兄的观点的区别，在于我更倾向于从外部（业务、客户）的角度来去看待产品、软件和设计、程序；而你更倾向从内部（数据、算法、技术）。

《人月神话》作者Brooks说的好，软件开发中，最最困难的，本质的困难，就是需求规格，其实也就是业务的分析，我总是乐意从外部来看程序开发，也是基于这个理由，分析业务、描述业务如果清楚了，那么你的程序基本上就成功了一大半。

当然我并不是排斥工具，例如Ioc、ORM；只是想说，这些东西在产品开发中的位置和重要程度是不同的，作用也是不同的。

8 楼 mike.liu 2013-05-29  

windshome 写道

欢迎mike.liu再次光顾我的文章，你的基础知识和功底比我丰富，向你学习。

我的意见是，你要表达数据结构，根本无需ORM。ORM的增删改查本身只是一种工具提供给上层的操作能力。具体的处理还得看业务。

很多的时候，ORM上是增删改查，而业务里边是另外的词汇，甚至，有很多业务要求，一个业务写多条数据，删除一些数据、修改一些数据，在一个事务里完成。这个时候，ORM里不掺和业务，只是提供一个操作数据的接口，上层业务流程组装这些东西。

关于业务和ORM的关系，我是这样理解的，欢迎批评指正：

程序=数据结构+算法

数据结构，在C里面就是struct，指针，数组等；在Java里面就是Bean，Object；在数据库里面，就是表结构，外键，关联表等。

业务其实是程序在另外一个层面的表述而已，所以每个业务必然包含数据和代码。

前辈大牛说，尽量把业务往数据里面塞，并提出以数据为中心进行程序设计，是因为这样设计出来的程序更健壮，更容易修改，更容易理解，更容易检查。

在Java企业级应用里面，最常用的数据就是Bean，Bean加上一些关系型的约束，就成为ORM，所以在企业级应用里面，把ORM与数据结构划等号，个人认为基本是没有什么问题的。如果这种理解没有错，那么就不能说ORM在业务分析和设计里面不重要。

当然在其它领域，比如桌面开发，可能对象直接在内存里面就可以了，大不了写到文件里面，这个时候是用不到什么ORM的。但是里面一样离不开数据。

7 楼 windshome 2013-05-29  

jinnianshilongnian，就是就是，我想，你的理解，是正确使用ORM。可惜目前很多人都不是这样，呵呵！我之所以说把它看成一个小工具或脚手架，也许也是一种“矫枉过正”的说法吧。

6 楼 雪飘寒 2013-05-29  

个人觉得orm框架只是对于技术层面来讲的，是技术框架

是框架还是工具，个人理解而已。

我的数据存到数据库中，或者硬盘中，或者文件里，都可以，那难道就把数据库和一个硬盘来等价吗，数据库的功能还是很多的。

5 楼 jinnianshilongnian 2013-05-29  

windshome 写道

欢迎mike.liu再次光顾我的文章，你的基础知识和功底比我丰富，向你学习。

我的意见是，你要表达数据结构，根本无需ORM。ORM的增删改查本身只是一种工具提供给上层的操作能力。具体的处理还得看业务。

很多的时候，ORM上是增删改查，而业务里边是另外的词汇，甚至，有很多业务要求，一个业务写多条数据，删除一些数据、修改一些数据，在一个事务里完成。这个时候，ORM里不掺和业务，只是提供一个操作数据的接口，上层业务流程组装这些东西。

其实探讨了半天，说白了ORM跟什么业务本来就没有啥关系。

4 楼 jinnianshilongnian 2013-05-29  

mike.liu 写道

mike.liu 写道

“数据压倒一切。如果已经选择了正确的数据结构并且把一切都组织得井井有条，正确的算法也就不言自明。编程的核心是数据结构，而不是算法。”--《Unix程序设计艺术》

人处理数据的能力比处理算法的能力强。

在业务系统中，ORM就对应数据结构。尽量把业务逻辑塞到ORM中去，所有的算法基本就变成ORM的增删改查操作了。

另外，几乎没有ORM不能表达的数据结构吧？ORM无论是工具也好，框架也好，怎么把它用好是最重要的。

ORM是一个映射器，而不是数据结构； O和R是数据结构。所以O和R才是核心，M用来协调它们之间的不匹配的。

3 楼 windshome 2013-05-29  

欢迎mike.liu再次光顾我的文章，你的基础知识和功底比我丰富，向你学习。

我的意见是，你要表达数据结构，根本无需ORM。ORM的增删改查本身只是一种工具提供给上层的操作能力。具体的处理还得看业务。

很多的时候，ORM上是增删改查，而业务里边是另外的词汇，甚至，有很多业务要求，一个业务写多条数据，删除一些数据、修改一些数据，在一个事务里完成。这个时候，ORM里不掺和业务，只是提供一个操作数据的接口，上层业务流程组装这些东西。

2 楼 mike.liu 2013-05-29  

mike.liu 写道

“数据压倒一切。如果已经选择了正确的数据结构并且把一切都组织得井井有条，正确的算法也就不言自明。编程的核心是数据结构，而不是算法。”--《Unix程序设计艺术》

人处理数据的能力比处理算法的能力强。

在业务系统中，ORM就对应数据结构。尽量把业务逻辑塞到ORM中去，所有的算法基本就变成ORM的增删改查操作了。

另外，几乎没有ORM不能表达的数据结构吧？ORM无论是工具也好，框架也好，怎么把它用好是最重要的。

1 楼 mike.liu 2013-05-29  

“数据压倒一切。如果已经选择了正确的数据结构并且把一切都组织得井井有条，正确的算法也就不言自明。编程的核心是数据结构，而不是算法。”--《Unix程序设计艺术》

人处理数据的能力比处理算法的能力强。

在业务系统中，ORM就对应数据结构。尽量把业务逻辑塞到ORM中去，所有的算法基本就变成ORM的增删改查操作了。