论Hibernate,狭隘化了的ORM模型

Hibernate典型的映射关系

1. Class <-> Table

一个Class一般可以映射为一个Table，一个Class的实例对应Table的一行数据。但是，一个Table中的每行数据，一般都需要有一个主键来唯一标识这行数据，而一个Class的每个实例，则不一定需要一个唯一标识。

2. Property <-> Field

一个Class的Property一般可以直接映射为Table的一个Field。但是，他们的数据类型不一定直接匹配。如果他们代表的数据类型的语义上可转换，则Field的类型，应大于等于Property的数据类型。如果他们代表的类型语义上不可转换，则需要在应用程序层面，进行自定义的转换。

这种映射太狭隘了,它要求:R是固定的,而O和M是相关的,即映射关系是预先定义好的,因此类和表结构是按照映射关系对应起来的,这样是不是太死板了,相应地导致了维护的复杂性

但是,我认为广义的ORM应该是:O是独立,M也是独立的,而R是可变的,即类和表结构是独立存在的,它们之间通过动态的映射关系进行关联起来,这样无论是类结构变化,还是表结构变化,或者两者全部变化,我们只需要动态调节映射关系就可以了


举个简单的例子:
Hibernate要求BO类与表结构一一对应,无论是改表结构还是改类,另一方都要进行相应的变化,维护起来何其麻烦,需要开发人员与DBA进行更多地协调工作

而且我们进行数据库查询的时候,往往也不是查询某一张表,复杂的业务逻辑往往是需要我们进行多表关联然后取其中几个字段而已

我们的类的定义往往是按照业务逻辑来划分的,而数据库表结构则考虑更多的是数据的共享和冗余,关注点经常不是一致的,这种情况下,我们不但需要建立诸多和表结构一致的类,还要再自定义和逻辑相关的类,然后不断地从各个BO对象中拷贝属性到一个业务逻辑类,这些无聊的重复的工作无疑增加了工作量,而且产生不了效率

而理想的情况下是,后台表结构按照最合适的方式存储,而应用程序根据业务逻辑抽取出数据字段映射到我们的业务逻辑类,完全没有必要类和表一一对应,除非某个表恰好构成了我们的一个业务逻辑,这样我们定义这么一个和表结构相同的类,但这也仅仅是巧合,以后需求变更了,表结构和类都可以各自独立的变化,没有相互约束

ORM就是对象和数据的映射,这种映射可以是静态的,也可以是动态的,可以是预先定义好的,也可以根据需求自动生成的,就目前我看来,Hibernate大抵属于前者,这也许就是某些人不喜欢它的原因吧

Hibernate完全就是狭隘化了的ORM,却被一些人奉若圭臬~

评论

20 楼 runningship 2013-01-09  

我个人表示支持楼主,楼主多多交流啊

19 楼 woaiwofengkuang 2011-05-19  

感觉楼主好像在说是领域模型对象与数据实体对象。

其实在我们项目中。实体对象，也就起到一个封数据表中记录值，在页面与表之间作为数据的传输者而已。除这一点没有任何其它功用。而Hibernate正好将这一过程给透明化了。

18 楼 kjj 2011-05-19  

引用

完全没有必要类和表一一对应,除非某个表恰好构成了我们的一个业务逻辑

评价hihernate能做什么不能做什么首先要学的比别人多

无知还无畏了...............

你不懂hibernate不是你的错,不懂出来还吓唬别人就是愚蠢了知道不

hibernate 开始实现 其作者也说了,精华只有一个,orm  解决om的阻抗不匹配关系

你一再强调--对应不觉得自己无知么

弄一套狗屁不通的玩意,还强词夺理了,我看你上窜下跳,能蹦达出个啥来

靠卖嘴在je是混不下去的!!!!!!!!!!!!

17 楼 iday 2011-05-19  

只会抱怨而不深入思考的人永远都只会报怨。

16 楼 moss 2011-05-19  

还是jdbc来的舒服，效率有了，灵活性也有了，起始也不麻烦，比起需求的变更，jdbc多带来的工作量几乎可以忽略不计

15 楼 cats_tiger 2011-05-19  

建议楼主踏踏实实的学习一个月，再踏踏实实的用两年再评论，以免贻笑大方。

14 楼 fnet 2011-05-19  

Hibernate本就是一个数据库工具。它基于数据库，其很多特性都是数据库特性的延伸。

不要对Hibernate报以巨大期望，它只是一个工具，crud工具。如果你想得太多，那么你会失望更多。你只要把它当做一个和其他工具类、框架一样的工具去使用即可，尽量发挥它的优势，那就是你的成功了。

至于模型，Hibernate的实体类本身是用java类的方式去面向表，它的状态是和数据库联接在一起的，如果硬是把它想象成一种内存里“万能”的对象，那么就剑走偏锋了。

13 楼 holly2k 2011-05-19  

术业有专攻啊LZ，你想用一个东西解决所有问题那是不可能的，hibernate强大的地方正是在于单类对单表的情况。。。

12 楼 szcs10138456 2011-05-19  

xiangfei209 写道

我觉得楼主，讲的可以，讲的项目实际，他们说的好，只是一种理论化，支持楼主

是实际，可能你们还没到那一步

11 楼 xnnyygn 2011-05-19  

兩點：
1：取數據的時候會過載（Overload），也就是SELECT時候把你不需要的字段也SELECT了。假如你有"潔癖“的話，可能覺得ibatis那種“自由選擇“似乎比較好，但是Overload的好處在於可以在高速緩存中存放完整的數據對象，其次一個應用中的SELECT模式可以窮舉，可以按照模式修改表結構，第三Hibernate的HQL提供投影，還有map構造或者new構造，第四如果希望退到ibatis那種模式，使用NativeSQL就可以了，還提供ObjectTransformer。
2：映射關係很重要。假設存在關係實體A與實體B多對多，比如Book和Tag，我要獲取Book的Tags或者刪除Book中的一條Tag，這樣的操作在配置好映射之後，不用寫SQL就可以安全可靠地完成。換句話說，映射關係提供了“語法糖“一樣的效果。而且，假如你數據庫有所更改，ORM這邊可以修改映射，而不用修改類，這在數據庫移植的時候可能有用（比如保留字）。另外ORM的數據方言使得你在數據庫間切換很方便，比如測試用數據庫HSQLDB/H2，產品數據庫Oracle/MySQL，想想你直接寫SQL維護不同的分頁限制代碼就可以了。

10 楼 xiangfei209 2011-05-19  

我觉得楼主，讲的可以，讲的项目实际，他们说的好，只是一种理论化，支持楼主

9 楼 szcs10138456 2011-05-19  

什么鸟理论。除了一些比较复杂的统计型查询不宜用hibernate，其他完全可以胜任。你完全不理解hibernate。你知道面向对象吗？你知道为什么会有hibernate出现吗？你学过ORM的基本理念吗？你就认为关系表决定vo吗？你错了。正常的面向对象是从vo先建立开始的，然后再转换成关系表的。懂我意思？小鸟没成熟就不要乱评论别人的精华。还有就使建立BO是为了方便显示，不一定要建立的。最后就是记住没有一样东西是完美的。

8 楼 晨星★~雨泪 2011-05-19  

月经贴。。。

7 楼 nianien 2011-05-19  

kjj 写道

引用

Hibernate要求BO类与表结构一一对应,

井底之蛙,坐井观天,不了解就乱评一通,和尿急了拉大条是一个道理

那你给我说说，你hbm。xml配的都是大便啊？
别跟我讲可以配置视图，那和Hibernate么有一毛钱关系

6 楼 kjj 2011-05-19  

引用

Hibernate要求BO类与表结构一一对应,

井底之蛙,坐井观天,不了解就乱评一通,和尿急了拉大条是一个道理

5 楼 linlfx 2011-05-19  

鸟理念
事物都是相对的，你光看不好，不看好，能有什么好理念

4 楼 ppgunjack 2011-05-19  

BO的universe其实是更灵活也更精巧的orm，不过目的是读取的单向mapping

3 楼 nianien 2011-05-19  

ray_linn 写道

说了半天不还是Ibatis的概念。。。

和Ibatis没关系,理念的问题
就像设计模式,也许你就在用,只是没有意识到
用一个东西不难,关键是抽象

2 楼 池中物 2011-05-19  

谁规定了class和table是一一对应的。

1 楼 ray_linn 2011-05-19  

说了半天不还是Ibatis的概念。。。