转贴:最佳J2EE方案讨论之O-R Mapping: hibernate v.s. CMP,请大家讨论

03-04-01 kuaizxl
              

O-R Mapping

J2EE的标准是CMP Entity Bean,而实际应用中受到诟病最多的也是它。我们化了整整半年时间研究CMP2.0的开发方法,目前总算能够将代码量减少到70%,并且有希望减少到90%。我曾经很满足现有的成绩,但是当我真正地阅读了hibernate后,对CMP2.0的信心彻底动摇了。

hibernate至少比CMP2.0有以下优点:

1. 兼容性。 规范一模一样,实现各有不同,这是CMP的现状。用第三方O-R Mapping工具可以解决这个问题。

2. 保护智力投资。在了解了Orion, Weblogic, JBoss的CMP实现后,我不愿意再去学习Websphere 或者Resin的实现了。

3. 性能。

a. local v.s. remote, hibernate、JDO、Castor都是本地调用,CMP2.0虽然也有Local接口,但是Web层还是需要通过Remote接口访问EJB层的数据,序列化、网络调用、创建大量的对象,都是性能降低的原因。

b. transaction,J2EE提出了一个全新的事务模型(method-based descriptor),对程序员的开发确实是个“简化”,记得一本教程建议所有的EJB方法都用Required。但这样的结果是什么? 性能极度降低!互锁!没有办法,我们只有再去调节各个方法的Transaction属性,然后又出现 新的互锁...

新的事务模型是不成功的。它试图简化问题,却引入了更为严重的问题。各家厂商的Transaction实现也不尽相同,有的支持Optimistic Lock,有的在VM中同步Entity对象,又是兼容性的一大敌。

hibernate没有试图创造一个更新的模式,相反,它沿用了传统数据库的Transaction编程模式,在对J2EE的Transaction伤透脑筋后看到它,真是十分亲切,感觉自己确实在编程,而不是碰运气填代码了。

4. 动态Query。

Entity Bean很难实现动态Query,这是因为它基于代码自动生成技术,即最终的执行代码是在部署编译时生成的。hibernate则有根本的改变,它基于reflection机制,运行时动态Query是很自然的事。另外,hibernate几乎支持所有的SQL语法,传统数据库可以做的它就可以做。

5. 发展速度。

I have a dream, 有一天Entity Bean会变得很好。但至少目前来看,Entity Bean是一个不完善的产品,它是大公司政治斗争和妥协的产品,而且习惯性将一些问题“无限期搁置”,典型的例子就是Query(之所以不提其他问题,是因为其他都是Entity Bean的致命伤:))

形成强烈反差的是,hibernate的核心程序员只有一人,但它改进的速度确是Entity Bean无法企及的。

6. 继承和多态。

OO语言的精华在Entity Bean这里是行不通的,我曾经自我安慰将Entity Bean看做一个“内存中的数据表”,才找到了一点平衡。

但当我看到hibernate时,又开始不平衡了。

另外,CMP2.0也有一些缺点是可以弥补的。

1. 代码维护。

大量的接口文件和配置文件,开发和维护的工作量很大。

解决途径:采用xdoclet,可以自动产生众多的接口和配置文件,甚至facade, delegate等高级模式。

至少目前来看,hibernate的缺点有:

1. 代码维护

hibernate提供了自动生成mapping文件“框架”的工具,但还需要手工调节。而这类开发,能想到的最佳模式就是xdoclet的(代码+注释)的模式了。幸好,hibernate的程序员已经向xdoclet项目增加了hibernate的模块。现在需要的是等待xdoclet的下一个release。

结论:

hibernate至少从文档上超越了Entity Bean很多,我要学习hibernate。

主页:

hibernate.sourceforge.net

有愿意一起研究hibernate的大家多交流交流。

guty

guty2001@sina.com

              

banq
2003-04-01 14:52

对于CMP 我只能说:没有更好,只有合适。

其实你的问题主要是处理transaction上,如果手工使用JTA,你还是会伤脑筋的,因为这是个应用问题,要仔细分析你的业务对象,哪些过程是必须事务的,一般在产品的1.0都会去掉transaction,这样顺利多,等产品相对稳定成熟,这时再考虑transaction。

将entity bean想像成内存中的一张数据表,这是符合entity bean原理的,不要将太多重担压在entity bean的CMP上,对于复杂的SQL,BMP是好的选择,有种CMP-BMP模式:先使用BMP,等以后QL丰富后,再稍微改动一下就可以回到CMP,推荐你这种方式。

还有,其实大量数据库操作中有一半是查询,大量查询建议你使用DAO模式。

banq
2003-04-01 14:53

我主要想说的是:选择框架软件最好是主流,hibernate可能很好,但是生命力有多长?如果主要开发者停止了,你的产品也就陷入停顿发展。

wys1978
2003-04-01 15:03

我觉得JDO会是一个比较好的O/R mapping的规范, 感觉它会成为以后的趋势, :)

banq
2003-04-01 16:08

我觉得,JDO最大的缺点是性能优化很难,其实这也是EJB的问题,这个问题不解决,JDO如果只是提供使用上便利的话,想真正代替实体bean比较难。

我曾经使用过Castor,这东西用好了,很方便,但是在用的时候,摸索很长时间,不知道哪里多个空格还是少写点什么,我反复删除,重写了好几次,总算碰巧调通了,最后不知道问题在哪里,让人生畏。

而开放CMP时,由于使用Jbuilder 几乎没有什么问题,看来,越是自动化的东西,支持的开发工具就越重要。

33Go 1 2 3 4 ... 33 下一页