OR Mapping技术--软件工程的死敌

Java软件开发员们都知道有一个MVC架构,其中最底层Model层目前流行的是OR
Maping的技术.面向对象的痴迷者想把什么都对象化,苦苦想将关系数据库变为面
向对象的数据库,经过十多年的实践证明, 这种想法是不现实的, 面向对象的数据
库至今没有商品化的产品. 于是面向对象的痴迷者创造出OR Mapping技术(例如
OJB,Hibernate).

笔者看来,用OR Mapping完全没有必要, 用了OR Mapping加重了项目开发难度,
延长了开发周期, 项目维护也困难了. 为什么会这样呢? 因为你一旦使用诸如
Hibernate的东西, 程序至少多出两层, 一个是VO层, 一个Dao层. 这会逼你写
一大堆和业务无关的,只是为了实现这个架构所需要的代码.(当然可能会有一些
工具自动产生这些架构所需要的代码), 所有这些做法是和软件工程的原则相违
背的.

软件工程的原则要求重用性, 越是底层的类越要有重用性, 越应该和业务逻辑无关.
我们总不能稍微改变一下业务逻辑就要求Oracle重写一个数据库服务器软件吧, 但是
OR Mapping的类却不是通用的类. 如果业务逻辑改变了, 例如需要在一个表里增加
一个字段, 那么用OR Mapping的开发人员不得不从最底层改到最高层. 每一层都
要改, 每一层都是不通用的!

软件工程的原则要求写程序应该直接了当, 不应该过度设计, 能精简尽量精简,
不要为分层而分层. 好的架构应该让程序员只写业务逻辑的代码,而用了OR
Mapping后, 程序员不得不花时间去产生一大堆只是为了满足架构需要的代码.

用OR Mapping的面向对象的技术查询数据库永远不可能象SQL语言一样灵活, Hibernate
的HBL查询也只能做一些简单的查询, 复杂的sql查询是OR Mapping技术无法替代的.

其实不用OR Mapping的技术早就有了, 以前做C/S软件的时候, 象VB使用ADO访问数据库,
PB使用DataWindow访问数据库. VB的ADO和PB的DataWindow都是访问数据库的通用底层
组件. 如今做B/S软件了, 也已经出现了.net架构使用的ado.net这个通用组件, 其实
Java也有自己的RowSet和CachedRowSet组件. 用通用组件去访问数据库要比用OR Mapping
方法更先进而高效.