Entity Bean vs Hibernate Pojo

转载 2012年03月30日 11:35:27

该文转自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

求助!第一个hibernate程序报错 org.hibernate.MappingException: Unknown entity: com.pojo.User

求助求助 对着案例看了好久- -找不到哪里不对,为什么报错了呢,工程目录hibernate.cfg.xml...

JavaBean,Entity Bean,Enterprise Bean等Bean以及POJO的含义

我的整理与总结: 一、对于java bean,就是一个java模型组件,他为使用java类提供了一种标准的格式,在用户程序和可视化管理工具中可以自动获得这种具有标准格式的类的信息,并能够创建...

浅谈JavaBean,Entity Bean,Enterprise Bean等Bean以及POJO的含义

我的整理与总结: 一、对于java bean,就是一个java模型组件,他为使用java类提供了一种标准的格式,在用户程序和可视化管理工具中可以自动获得这种具有标准格式的类的信息,并能够...
  • kdsde
  • kdsde
  • 2014年08月28日 11:15
  • 474

EJB学习(六)——Entity Bean 和 Hibernate的比较

在学习EJB的Entity Bean这一块的时候,感觉它和Hibernate是一样一样的,把当初总结Hibernate的导图找了出来,经过对比,感觉两个几乎是差不错的,下面就在Hibernate的基础...

entity、pojo、javabean等的理解区别(都是某种对象)

JavaBean: 是一种Java语言写成的可重用组件,它的方法命名,构造及行为必须符合特定的约定。   POJO(Plain Ordinary Java Object):POJO就是一个简单的...

Java中的对象(PO,BO,VO,DTO,POJO,DAO,Entity,JavaBean,JavaBeans)

文章转载自:http://www.cnblogs.com/lyjin/p/6389349.html PO:持久对象 (persistent object),po(persistent objec...

Java各种对象(PO,BO,VO,DTO,POJO,DAO,Entity,JavaBean,JavaBeans)的区分

原文地址:http://www.cnblogs.com/lyjin/p/6389349.html PO:持久对象 (persistent object),po(persistent object)就...

Entity_Bean

  • 2012年11月04日 11:08
  • 1.13MB
  • 下载
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Entity Bean vs Hibernate Pojo
举报原因:
原因补充:

(最多只允许输入30个字)