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

 

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

 

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

 

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

 

 

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

 

 

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

 

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

 

 

 

 

 

 

 

 

 

   

评论

11 楼 damoqiongqiu 2013-05-29  

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

10 楼 LeoChowComtop 2013-05-29  

LeoChowComtop 写道

轻量的rom我是喜欢的，当然，我从不用hibernate什么的，rom在我的定位就是一直是工具的东西。ROM思想本身是不错的，只是很多时候把它定位的权重过高而已。

好吧ORM，打错了，最近研究硬件来着

9 楼 LeoChowComtop 2013-05-29  

轻量的rom我是喜欢的，当然，我从不用hibernate什么的，rom在我的定位就是一直是工具的东西。ROM思想本身是不错的，只是很多时候把它定位的权重过高而已。

8 楼 windshome 2013-05-29  

我一个是同意 jinnianshilongnian 说的，ORM简化了一些工作，其实还有一点，让开发人员都以对象方式来处理数据存取。分歧是我觉得ORM应该只是一些小工具，类似于构建高楼大厦时的脚手架而已。

须等待老兄，你说的不易驾驭深得我心。我自己写的基于JDBC的方式，因为积累了很多底层的公共代码（有些是API库），让上层开发也一样非常简单。

7 楼 须等待 2013-05-29  

jinnianshilongnian 写道

须等待 写道

在快速开发的领域，hibernate还是有它的作用的，称之为框架，就是它可以简化不少工作，让专注于业务的程序更专注于业务，简化底层的操作。

不过我也非常不喜欢ORM，因为可控性太差，说实话我宁愿多写一点代码，或者用自己封装的框架

只能说我们有时候驾驭不了它。各有所长。

同意，这种框架一点让我很讨厌的就是出了问题很难去定位，换句话说就是驾驭不了。hibernate尝试把很多功能都以统一的解决方案集成到它框架里面，好处多多，不过在现在这种替代方案更多且思路架构更清晰的时代，我还是更加倾向于用不那么集成的、架构更清晰的解决方案。

6 楼 windshome 2013-05-29  

首先感谢各位的回复，你们的回复让我考虑更多问题，对我的成长非常有帮助。因为ITEye回复功能我一直用不好，所以我单独写了一篇给各位的回复，http://windshome.iteye.com/blog/1879212，希望各位关注，并继续指教小弟。


写的时候没有看到  须等待 老兄的回复和后面的回复，做一个补充，在做产品时，我的确也更在意程序员是否能驾驭整个产品的设计和代码，对开发阶段的速度和工作量没有那么在意（我的意见，代码多少不等价于系统复杂度高和难理解）。因为出了问题，是否能找到处理方法，是否能够得到社区的支持真的不好说。但是客户不干啊。

5 楼 jinnianshilongnian 2013-05-29  

须等待 写道

在快速开发的领域，hibernate还是有它的作用的，称之为框架，就是它可以简化不少工作，让专注于业务的程序更专注于业务，简化底层的操作。

不过我也非常不喜欢ORM，因为可控性太差，说实话我宁愿多写一点代码，或者用自己封装的框架

只能说我们有时候驾驭不了它。各有所长。

4 楼 须等待 2013-05-29  

在快速开发的领域，hibernate还是有它的作用的，称之为框架，就是它可以简化不少工作，让专注于业务的程序更专注于业务，简化底层的操作。

不过我也非常不喜欢ORM，因为可控性太差，说实话我宁愿多写一点代码，或者用自己封装的框架

3 楼 Allen 2013-05-29  

整了半天，还是在讨论“业务逻辑”究竟是放在应用程序里面，还是放在数据库层面啊……有点标题党了。

2 楼 dwangel 2013-05-29  

楼主做的系统不够多，涉及的数据类型没有达到一定的数量级。
而且不是大团队作业。

当业务对象极为众多和复杂时，为了简化问题，往往是先对业务对象建模
然后分解 业务逻辑的。通过业务对象模型的一致性，来保证业务逻辑的粘合。

ORM就是为了简化 业务对象建模后的存取而出现的。

1 楼 jinnianshilongnian 2013-05-28  

ORM的核心是自动化对象和关系映射，其他的都是扩展。正如之上你引用的，这也是orm的核，我见过很多项目仅仅使用了这个核，比如关系映射/二级缓存，如果不熟悉，还不如直接不用。

引用

ORM根本就是系统中的一个小工具层，不应当称为“框架”。

对于工具和框架的解释，我参考下GoF的：

引用

2. 工具箱
一个应用经常会使用来自一个或多个被称为工具箱( To o l k i t )的预定义类库中的类。工具箱
是一组相关的、可复用的类的集合，这些类提供了通用的功能。工具箱的一个典型例子就是
列表、关联表单、堆栈等类的集合， C + +的I / O流库是另一个例子。工具箱并不强制应用采用
某个特定的设计，它们只是为你的应用提供功能上的帮助。工具箱强调的是代码复用，它们
是面向对象环境下的“子程序库” 。

引用

3. 框架
框架( F r a m e w o r k )是构成一类特定软件可复用设计的一组相互协作的类 [ D e u 8 9 , J F 8 8 ]。例
如，一个框架能帮助建立适合不同领域的图形编辑器，像艺术绘画、音乐作曲和机械
C A D [ V L 9 0 , J o h 9 2 ]。另一个框架也许能帮助你建立针对不同程序设计语言和目标机器的编译
器[ J M L 9 2 ]。而再一个也许能帮助你建立财务建模应用 [ B E 9 3 ]。你可以定义框架抽象类的应用
相关的子类，从而将一个框架定制为特定应用。

引用

这个层次的复用导致了应用和它所基于的软件之间的反向控制 (inversion of control)。当
你使用工具箱(或传统的子程序库)时，你需要写应用软件的主体并且调用你想复用的代码。而
当你使用框架时，你应该复用应用的主体，写主体调用的代码。你不得不以特定的名字和调
用约定来写操作地实现，但这会减少你需要做出的设计决策。
你不仅可以更快地建立应用，而且应用还具有相似的结构。它们很容易维护，且用户看
来也更一致。另一方面，你也失去了一些表现创造性的自由，因为许多设计决策无须你来作
出。

从这里看称为工具，概念有点小。比如apache dbutils 这才是工具，一些主体代码还是需要我们写的。而上了如ORM/如spring jdbc后，如元数据/约定，可以只写主体调用代码。所以我还是认为它是个框架。

引用

我们更不能让这些东西干扰我们的设计。

我想问下，用了ORM就干扰我们的设计了？怎么干扰的？此处没想明白，希望得到指点。比如实际用时我可能封装到Repository中，以一个仓库对象提供给业务对象，对它来说是没什么的干扰的。

其实ORM有时候能帮我们做不少事情，我认为这个是合适的情景选择合适的工具的问题。如果在一个OLAP场景下选ORM说ORM不好，那无话可说。

正如很多问 hibernate好还是ibatis好还是jdbc好？ 我坚持的是合适的情景选择合适的工具。


浅见，多多批评。