论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,却被一些人奉若圭臬~

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

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

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

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

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

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

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

月经贴。。。

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