| |
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。
|
|
