现在的位置: 首页 > 综合 > 正文

hibernate使用关联映射的优劣比较:为什么用Hibernate时一定要做关联映射?

2013年05月30日 ⁄ 综合 ⁄ 共 2281字 ⁄ 字号 评论关闭

http://drinkjava.javaeye.com/blog/82107?page=2#comments

读过上文以后有很多感慨:技术上的、心情上的。

作者提出了一种迥异的、全新的hibernate使用方法。

可是如果都这样做系统,那还怎么显示出对OR精通的各位牛人的价值呢?

怎么能21世纪还是用ER模型呢?

所以作者的文章当然得不到javaeye各位"大拿"、“主流”的承认了,又是评为新手帖,又是锁定帖子的。根本连一个敢出来辩论一下的人都没有。心寒。

中国文人相轻的风俗还真是千年不变。

个人对作者的想法表示钦佩,而且感觉极具可操作性。因为作者的做法及其简单,简单到不行。

总结一下作者提到的方法的优劣:
作者总结的优点:
1、简单易学。
2、得到了大部分Hibernate的优点:不用手工写SQL,对象级别缓存,数据库可移植性。
3、在新手多、 工期短的项目中,可节省很多培训时间,而且对于后来维护者的要求也大大降低。这是项目中很        具体很现实的问题。
4、可以完全抛开openSessionInView。
更多的优点:
5、可以更容易的编写从数据库-〉hibernate的工具。有了工具就能更好的保证数据库和pojo的一致性。从我使用Hibernate的经历看, hibernate最缺少的就是能保证pojo和数据库保持一致的工具。这导致了复杂的容易出错的配置,即使是使用注解也是一样。这样说是因为我用过在这 方面做的极好的工具。

作者总结的缺点:
1、不能在HQL中写出"...object1.object2.object3..." 式的对象引用。
2、关联表的加载要自已来维护。
其实对于第一点,根本不能算是缺点。自己写个稍微复杂点的sql就是了。
第二点也不好说是不是缺点,因为有时明确控制关联表的加载反而比较好。
更多的缺点:
1、完全没有用到延迟加载。

如果作者看到这篇文章的话,可以考虑一下更多的选择:
既然你对ER非常熟悉,那么可以考虑只使用特定数据库的开发工具,这样能更进一步的提高开发效率。而不一定要在hibernate上吊死。
比如oracle form。
或者ruby on rail。

附原文:

为什么用Hibernate时一定要做关联映射?

关键字: Hibernate

我用Hibernate也有半年了,感觉Hibernate的映射关系太复杂了,与懒性加载,反转控制等结合在一起,要想控制好,实非常人之所能。个人感 觉,如果不用Hibernate的关联,就把它当作关系数据库来操作,使用和理解上都会方便不少,例如一个订单和产品的配置文件写成这样:
<hibernate-mapping>
<class name="db.Order" table="orders" catalog="sample">
<id name="id" type="java.lang.String">
<column name="ID" length="32" />
<generator class="uuid.hex" />
</id>
<property name="orderTitle" type="java.lang.String">
<column name="ORDER_TITLE" length="30" />
</property>
</class>
</hibernate-mapping>

<hibernate-mapping>
<class name="db.Product" table="products" catalog="sample">
<id name="id" type="java.lang.String">
<column name="ID" length="32" />
<generator class="uuid.hex" />
</id>
<property name="productTitle" type="java.lang.String">
<column name="PRODUCT_TITLE" length="30" />
</property>
<property name="orderId" type="java.lang.String">
<column name="ORDER_ID" length="32" />
</property>
</class>
</hibernate-mapping>
操作时:
Order o=new Order();
o.setOrderTitle("order1");
dao.saveOne(o);
Product p=new Product();
p.setProductTitle("product1");
p.setOrderId(o.getId());
dao.saveOne(p);
(HQL查询则仿照普通SQL中的写法,此处略)
这样一来,纯粹是用关系数据库的思想来使用Hibernate,一个类对应一个数据库表,表之间的约束交给数据库的键来控制, 这样一来,即得到了Hibernate的优点:不用手工写SQL,对象级别缓存,数据库可移植性,也不必费力地学习和理解它了,纯粹是一个薄薄的JDBC 的包装; 缺点就是不能在HQL中写出"...object1.object2.object3..." 式的对象引用,而且关联表的加载要自已来维护,但我认为相对于理解它复杂的配置来说,这点牺牲还是值得的, Hibernate的高级特性当然没法用上了,但相比于直接用JDBC或用ibatis写SQL总要好得多,只要会关系数据库,就能立即上手,在新手多、 工期短的项目中,可节省很多培训时间,而且对于后来维护者的要求也大大降低,请问我的这种想法是否可行?

 
  

抱歉!评论已关闭.