您当前的位置：首页 > 阅读中心 > 软件学习

最佳J2EE方案讨论之O-R Mapping

时间：2014-05-04 10:04:16 来源：不详作者：佚名

　　J2EE的标准是CMP Enti
年时间研究CMP2.0的开发方
曾经很满足现有的成绩，但

ty Bean，而实际应用中受到诟
法，目前总算能够将代码量减少
是当我真正地阅读了hibernate

病最多的也是它。我们化了整整半
到70%，并且有希望减少到90%。我
后，对CMP2.0的信心彻底动摇了。

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

　　1. 兼容性。规范一模
具可以解决这个问题。

一样，实现各有不同，这是CMP

的现状。用第三方O-R Mapping工

　　2. 保护智力投资。在
Websphere 或者Resin的实

了解了Orion, Weblogic, JBoss
现了。

的CMP实现后，我不愿意再去学习

　　3. 性能。

　　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编
筋后看到它，真是十分亲切，感觉自己确实在编程，

　　4. 动态Query。

　　Entity Bean很难实现
码是在部署编译时生成的。
Query是很自然的事。另外
以做。

动态Query，这是因为它基于代
hibernate则有根本的改变，它
，hibernate几乎支持所有的SQL

码自动生成技术，即最终的执行代
基于reflection机制，运行时动态
语法，传统数据库可以做的它就可

　　5. 发展速度。

　　I have a dream, 有一
个不完善的产品，它是大公
，典型的例子就是Query（
）

天Entity Bean会变得很好。但
司政治斗争和妥协的产品，而且
之所以不提其他问题，是因为其

至少目前来看，Entity Bean是一
习惯性将一些问题“无限期搁置”
他都是Entity Bean的致命伤：）

　　形成强烈反差的是，hi
Bean无法企及的。

bernate的核心程序员只有一人

，但它改进的速度确是Entity

　　6. 继承和多态。

　　OO语言的精华在Entity Bean这里是
“内存中的数据表”，才找到了一点平衡

行不通的，我曾经自我安慰将Entity Bean看做一个
。

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

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

　　1. 代码维护。

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

　　解决途径：采用xdoclet,可以自动产
高级模式。

生众多的接口和配置文件，甚至facade, delegate等

　　至少目前来看，hibernate的缺点有：

　　1. 代码维护

　　hibernate提供了自动
发，能想到的最佳模式就是
经向xdoclet项目增加了hib

生成mapping文件“框架”的工
xdoclet的（代码+注释）的模式
ernate的模块。现在需要的是等

具，但还需要手工调节。而这类开
了。幸好，hibernate的程序员已
待xdoclet的下一个release。

　　结论：

　　hibernate至少从文档

上超越了Entity Bean很多，我

要学习hibernate。

来顶一下

返回首页

推荐资讯

后牧工业区厂房1500平	现实的童话公主艾米·
科比专为大场面而生	“最美清洁工”原是《

相关文章

无相关信息

栏目更新

栏目热门