其实,我认为,关系数据库与OO没有阻抗,这一观点是从外部(业务的角度)来看程序和系统,这样来看的话们我们把程序理解成一个故事,应当保存就保存,应当获取就获取,保存和获取是故事中的一些具体情节而已。
说到CRUD,就不是这个视角了,外部看,只有“将某个数据保存起来”和“取出来某个数据”而已。而这个“情节”,是永远需要的。
但“CRUD”却不是永远需要的,况且,即便从内部看,很多大型系统,根本就没有CRUD,只有“Save”和“Query”,所谓的“Update”,只是“Mark”和“Add”,因为要保存每一个数据的原始状态数据,不可能删除和覆盖;“Delete”更是不可能的,从来不会有需要删除的数据,即便是错误的,可以归档,可以Mark。
是否一天天陷身在系统内部,会有“不识庐山真面目,只缘身在庐山中”?从外部看,当行则行,当止则止,根本就没有矛盾。
转帖内容如下:
Pere Villega 的博文内容:
大部分信息系统都是持久化存储信息然后查询获取,这大部分是通过RDBMS完成的,不久NoSQL运动促使其成为一个关系数据库的替代者,总得来说,我们需要一个存储区域来保存数据。
但是,这不代表没有问题,流行的开发模型是基于面向对象编程语言配以关系数据库,这种组合有致命的问题:对象和关系阻抗不匹配性,换句话说,他们并不能在一起工作得很好,这其中有许多原因。
这不是一个新问题,人们也在艰难努力提供新的解决方案以消除痛苦,从一个开发者角度看,ORM可能缓解一下这种不匹配问题,即使只是稍微低,像Hibernate这样的工具负责与关系数据库层打交道,这样开发者不必花费时间在这上面,但是这并不完美,由于抽象泄漏定律使得问题变得棘手,任何使用过Hibernate的人都发现通过其框架实现的查询都不够完美,那就意味着开发者必须钻研得很深以便知晓如何告诉框架让它按自己的意图行事,这也通常意味着你进入了底层低级别,包括数据库层,阻抗不匹配问题又冒出来了。
这样,ORM作为一个完整的解决方案失败了。
banq的博文: