Entity Bean vs Hibernate Pojo

 

该文转自guty

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。

以下是robbin的观点

如果说不使用Session Facade模式的话，我认为EB还是一个很有意义的的东西，因为EB是唯一直接支持跨RMI的持久化方案。但是由于EB的效率和减少跨RMI的网络调用的原因，EB已经完全被封装到SB的后面，EB的分布式调用的功能，EB的安全验证功能，EB的容器事务功能完全被前面的SB给做了，结果EB就只剩下了唯一的ORM功能了，单就ORM这一点来说EB实在是一个非常非常糟糕的东西。那么EB还有什么功能值得我非去用它不可呢？

用 Session Bean + DAO + Hibernate 来取代 Session Bean + Entity Bean，不但能够极大降低软件设计难度，软件开发难度，软件调试难度和软件部署难度，而且还可以提高允许效率，降低硬件要求。

不要把EB直接拿来和Hibernate做比较，两者不是一个范畴的东西，而应该整体比较两种方案：
Session Bean + DAO + Hibernate
Session Bean + Entity Bean
我找不出来第二方案有哪怕一点方面能够比第一方案好的。

CMP可以使用CMR来表示多表之间通过外键关联的关系。但是你仍然会遇到即使没有键关联的表仍然需要连接查询的情况，这是一个非常普遍的现象。

如果是Hibernate，可以在HSQL里面定义outer join，BMP也可以写JDBC，而CMP没有任何办法来解决该问题，除非你把需要的连接查询都定义为CMR，但那样的话，凡是有需要连接查询，或者有键关联的表都必须打在一个包里面。你如果不打在一个jar包里面，如果能够建立CMR？不是我想放在一个jar里面，而是不得不放在一个jar里面。基本上CMP还是非常笨拙的。

CMP的另一大缺点是不能动态SQL，guty已经提到了，一个SQL就要定义一个EJBFinder方法，在编译的时候就确定死了。在实际应用中，经常会遇到不确定查询条件的查询，比如说用户在页面上用下拉列表来选择查询的条件，用户既有可能什么限制条件都不选，也有可能选择某几个条件。这时候你怎么办？假设有n个查询条件，你要写 C1n + C2n + C3n +...+ Cnn(C是组合公式的符合，n是下标，1...n是上标)个EJBFinder方法才行，很恐怖吧。

其实JDBC的PrepareStatement也不能很好的解决这个问题，因为它是按照1，2这样的次序来set参数的。用Statement是肯定不行的，会严重影响数据库，甚至会导致数据库down掉(我的实际经验)。但是Hibernate就解决的不错，因为它可以按照 :name 这样的形式来设定SQL中的Placeholder，这样set参数就可以按照参数名称传递，因为次序不是死的，在程序里面就很容易根据用户选择的查询条件，动态的产生SQL，动态的set参数了。

CMP2.0还有一个大问题是不支持order by，当然你可以在Java里面对取出来的集合排序，但是速度和数据库里面就排好序速度不在一个数量级了。Hibernate不但可以order by，还可以group by，having，子查询，真是没有办法比下去了。

其实对于动态SQL和排序问题，特定的App Server也可以做，但那不是CMP2.0的规范罢了，所以为了可移植性，也不敢随便去用。

在项目开发时， 开发和运行效率以及灵活性是非常重要的指标。由于Entity Bean天生是一种粗粒度的使用方式，这就必定使它在装载的时候有较长的响应时间，也不能自如的支持懒装入的方式，使用成细粒度会使程序变得复杂，以及远程调用细粒度的entity bean是一种非常可怕的行为, 太慢了.

Hibernate正好满足开发和运行效率以及灵活性，说来说去，它可以称做一个OO化的JDBC, 这样大家就不会对Hibernate产生误解及恐惧心理。它支持粗细两种粒度方式，运用起来灵活自如，前提是你必知道如何使用，一个entity bean 实现要N种重复的方法, such as ejbRemove,ejbstore,ejb...., 光类也有一大堆，象Home Interface, Romote Interface..., Primary class if necessary. Hibernate只需要一个就行了。

CMP在进行O/R Mapping方面只是做了最基础的工作而已，完全用CMP做数据层，会发现你在把数据库应该做的工作全部都搬到App Server里面来重新实现一遍，有这必要吗？

CMP是把EJBQL写死在ejb-jar.xml里面的，所以n个条件就需要(c0n+c1n+...cnn )2的n次方个EJBFinder方法，简直没有办法说。

JDBC实现PrepareStatement的动态SQL构造不是不能够，而是非常麻烦，需要写一个非常非常大的if elseif else嵌套的判断。

Hibernate实现起来特别简单，（其实OJB也实现了PrepareStatement的动态SQL构造）这本身并不复杂，但是需要你多写些代码而已，由于CMP把EJBQL写死在配置文件里面了，你连选择的余地都没有。