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

2019-11-18 12:28:54

字体：大中小

来源：转载

供稿：网友

　　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。

上一篇：solaris上开发J2EE应用中文问题的解决

下一篇：J2EE应用系统内部的Web Services