最佳J2EE方案讨论之O-R Mapping |
作者:佚名 发布时间:2005-04-02 来源:不详
|
J2EE的标准是CMP Enti 年时间研究CMP2.0的开发方 曾经很满足现有的成绩,但
|
ty Bean,而实际应用中受到诟 法,目前总算能够将代码量减少 是当我真正地阅读了hibernate
|
病最多的也是它。我们化了整整半 到70%,并且有希望减少到90%。我 后,对CMP2.0的信心彻底动摇了。
|
1. 兼容性。 规范一模 具可以解决这个问题。
|
一样,实现各有不同,这是CMP
|
的现状。用第三方O-R Mapping工
|
2. 保护智力投资。在 Websphere 或者Resin的实
|
了解了Orion, Weblogic, JBoss 现了。
|
的CMP实现后,我不愿意再去学习
|
a. local v.s. remote, hibernate 接口,但是Web层还是需要通过Remote接 对象,都是性能降低的原因。
|
、JDO、Castor都是本地调用,CMP2.0虽然也有Local 口访问EJB层的数据,序列化、网络调用、创建大量的
|
b. transaction,J2EE提出了一个全 员的开发确实是个“简化”,记得一本教 是什么? 性能极度降低!互锁!没有办 ,然后又出现 新的互锁...
|
新的事务模型(method-based descriptor),对程序 程建议所有的EJB方法都用Required。但这样的结果 法,我们只有再去调节各个方法的Transaction属性
|
新的事务模型是不成功 Transaction实现也不尽相 是兼容性的一大敌。
|
的。它试图简化问题,却引入了 同,有的支持Optimistic Lock
|
更为严重的问题。各家厂商的 ,有的在VM中同步Entity对象,又
|
hibernate没有试图创造一个更新的 程模式,在对J2EE的Transaction伤透脑 而不是碰运气填代码了。
|
模式,相反,它沿用了传统数据库的Transaction编 筋后看到它,真是十分亲切,感觉自己确实在编程,
|
Entity Bean很难实现 码是在部署编译时生成的。 Query是很自然的事。另外 以做。
|
动态Query,这是因为它基于代 hibernate则有根本的改变,它 ,hibernate几乎支持所有的SQL
|
码自动生成技术,即最终的执行代 基于reflection机制,运行时动态 语法,传统数据库可以做的它就可
|
I have a dream, 有一 个不完善的产品,它是大公 ,典型的例子就是Query( )
|
天Entity Bean会变得很好。但 司政治斗争和妥协的产品,而且 之所以不提其他问题,是因为其
|
至少目前来看,Entity Bean是一 习惯性将一些问题“无限期搁置” 他都是Entity Bean的致命伤:)
|
形成强烈反差的是,hi Bean无法企及的。
|
bernate的核心程序员只有一人
|
,但它改进的速度确是Entity
|
OO语言的精华在Entity Bean这里是 “内存中的数据表”,才找到了一点平衡
|
行不通的,我曾经自我安慰将Entity Bean看做一个 。
|
大量的接口文件和配置文件,开发和维护的工作量很大。 |
解决途径:采用xdoclet,可以自动产 高级模式。
|
生众多的接口和配置文件,甚至facade, delegate等
|
hibernate提供了自动 发,能想到的最佳模式就是 经向xdoclet项目增加了hib
|
生成mapping文件“框架”的工 xdoclet的(代码+注释)的模式 ernate的模块。现在需要的是等
|
具,但还需要手工调节。而这类开 了。幸好,hibernate的程序员已 待xdoclet的下一个release。
|
hibernate至少从文档
|
上超越了Entity Bean很多,我
|
要学习hibernate。
|
|
|
|
|
|