分析某位高人对ORM的评价

 

其实，我认为，关系数据库与OO没有阻抗，这一观点是从外部（业务的角度）来看程序和系统，这样来看的话们我们把程序理解成一个故事，应当保存就保存，应当获取就获取，保存和获取是故事中的一些具体情节而已。

 

说到CRUD，就不是这个视角了，外部看，只有“将某个数据保存起来”和“取出来某个数据”而已。而这个“情节”，是永远需要的。

但“CRUD”却不是永远需要的，况且，即便从内部看，很多大型系统，根本就没有CRUD，只有“Save”和“Query”，所谓的“Update”，只是“Mark”和“Add”，因为要保存每一个数据的原始状态数据，不可能删除和覆盖；“Delete”更是不可能的，从来不会有需要删除的数据，即便是错误的，可以归档，可以Mark。

 

是否一天天陷身在系统内部，会有“不识庐山真面目，只缘身在庐山中”？从外部看，当行则行，当止则止，根本就没有矛盾。

 

转帖内容如下：

 

Pere Villega 的博文内容：

 

大部分信息系统都是持久化存储信息然后查询获取，这大部分是通过RDBMS完成的，不久NoSQL运动促使其成为一个关系数据库的替代者，总得来说，我们需要一个存储区域来保存数据。

但是，这不代表没有问题，流行的开发模型是基于面向对象编程语言配以关系数据库，这种组合有致命的问题：对象和关系阻抗不匹配性，换句话说，他们并不能在一起工作得很好，这其中有许多原因。

这不是一个新问题，人们也在艰难努力提供新的解决方案以消除痛苦，从一个开发者角度看，ORM可能缓解一下这种不匹配问题，即使只是稍微低，像Hibernate这样的工具负责与关系数据库层打交道，这样开发者不必花费时间在这上面，但是这并不完美，由于抽象泄漏定律使得问题变得棘手，任何使用过Hibernate的人都发现通过其框架实现的查询都不够完美，那就意味着开发者必须钻研得很深以便知晓如何告诉框架让它按自己的意图行事，这也通常意味着你进入了底层低级别，包括数据库层，阻抗不匹配问题又冒出来了。

这样，ORM作为一个完整的解决方案失败了。

 

banq的博文：

使用ORM相当于对象和数据库两个数据结构，因此存在阻抗矛盾，相反，因为SQL属于算法过程，SQL+数据库反而比较协调，但是做些CRUD还可以，应对复杂的业务，需要翻看各种数据表设计才能明白业务，数据库表又混杂了各种技术性能优化等技术方言，相当于方言夹带普通话，只通普通话(代表业务语言)的人不容易听通，增加沟通的难度。

后来有了Java等对象语言，就有了SQL+数据库+DTO数据Java对象，这就是大部分系统的特点，两个数据结构发生阻抗，改了数据库表还要改Java对象。

Hibernate试图协调对象和数据库两种数据结构矛盾，其实是清官难断家务事，捣浆糊而已，因为从逻辑上对象和数据表两者本来就没有必要搞到一起，搞个映射对应。

Hibernate出来很讨人喜欢，但是做些简单CRUD没有问题，随着项目深入，加上程序员数据库思维影响，使用Hibernate觉得隔着靴子瘙痒，其实我一直认为，如果程序员有阅读一个框架的源码冲动时，说明抽象泄漏已经发生，泄漏出来的坏味道已经让使用者心神不宁了。最终现实是：使用Hibernate的人是SQL与Hibernate两个要一起掌握，其实是增加学习成本。