作者 James Kao译者 宋玮 发布于 2008年1月16日 上午1时39分
java.net刊登了一篇由Sharad Acharya所写的名为Java Persistence Framework: Which, When, and What?的文章,文中比较了四种流行的持久化框架:CMP Entity EJBs、JPA、Hibernate和TopLink。Acharya讨论了每种技术并在一个表格中总结了他的结论,其结论归结为:
JPA
适合J2SE和J2EE的简单框架,并入了其他框架的许多有用特性,但是需要Java 5或更高版。
CMP Entity EJBs
J2EE容器所支持的框架,拥有安全和事务管理、很好的可伸缩性、以及分布式的组件能力,但是耗费资源且学习和使用较为复杂。
Hibernate
简单、灵活的框架,完全免费且易于与其他框架集成,但由于是开源的,因而可能有支持问题。
TopLink
Oracle的中心框架,十分成熟,但是使用它意味着绑死在一个单一厂商上。
该文章引发了相当数量的评论,尤其是围绕着JPA和EJB 3.0中的Entity Beans之间的关系、以及作为开源框架的Hibernate的潜在不利因素方面的评论。
一个评论者在其关于Entity Beans和JPA的评论中这样写道:另一个抱怨把开源作为一个不利因素的描述如下:该文章讨论了使用JDBC的Bean-Managed Persistence (BMP)与Container-Managed Persistence之间的对比,但是EJB3.0为实体bean持久化引入了一个全新的模型。我必须假设作者在这里讨论的是EJB 2.x。
“远程接口模型”的讨论也暗示了作者仍然在谈论EJB 2.x,而且他文章中的大部分针对Enterprise JavaBean的背景信息及所罗列的缺点实际上是对EJB 1.x和 EJB 2.x而言的,而非针对EJB 3.0。
这有点混乱,因为作者提及了EJB 3.0使用注解消除了许多伴随在以前版本EJB左右的编码困难。但是在下一个句子里他接着说道,“EJB架构的学习和使用绝非易事”,并且罗列了一些以前EJB版本的一些常见问题。
作者还谈到了EJB在其他框架中不能使用,但是EJB 3.0使用了“普通”Java类,它可以在其它框架中使用,只要这些框架忽略掉该普通Java类的JPA注解即可。
JPA作为EJB 3规范的一部分被创建,而且是EJB 3的固有部分。该规范制定者确定符合JPA规范的实现应当支持SE环境。该作者提到了JPA在EJB和SE环境下都可以工作,但是接着又说要使用JPA,Java EE 5是必须的。这不是事实,因为要使JPA工作,SE并不需要依赖于EE。
该篇文章所罗列的JPA的一个“不利因素”是JPA的能力受限于实现厂商。事实是“厂商”必须实现所有规范要求,包括Hibernate(它也是一个JPA实现的“厂商”)。有些人可能不得不自己写类库或框架,唯一的问题是他们所写的类库或框架是否与标准兼容。而其他一些人所涵盖的框架“可能”是基于标准的(构建在标准之上),Java对象关系映射持久化框架自身就是标准,它是一套Java持久化API。
EJB 3.0和JPA之间是单向依赖。任何EJB 3.0实现应当被预期为是大量基于JPA的,但是JPA出现并不意味着EJB必须出现,因为Java SE可以使用JPA。
我认为我不同意你关于“开源是不利因素”的直白叙述。实际上,这种论调具有一定的误导,它实际上可能会给你的项目增加不利因素。我所工作的一个项目决定用Kodo替代Hibernate,仅仅因为LGPL还不够友好(不利因素,等等)。当我看了代码之后我发现这是多么错误的一个决定……Hibernate那时远远胜出而且现在我仍然这么看。现在维护起来困难且棘手。工作量完全不一样……尽管如此,有些人还是插话表达对作者主张的支持:
开源项目通常“是”一个不利因素,而且Hibernate确实有严重的支持问题。除非你向该组织付费,否则你将发现他们的支持非常糟糕。Bug报告和特性要求将伴以粗陋的评论而被关闭掉。张贴在论坛上的讨论会被忽略。普通(免费)支持将来也会很困难。
任何正在考虑使用Hibernate的人应该认识到,90%的时间它会像魔法一样在工作,但是你将会浪费“数以天计”的时间修改那剩下的10%。他们通过使产品更难使用和掌控支持来获利,这是他们挣钱的方式,就像其他开源项目一样。
Hibernate最大的易用性问题是其异常消息。有时你会得到一个误导性的错误信息,把你引向一个错误的方向。还有时你会得到非常模糊的信息,让你无法判断什么地方出了错。如果你提出一个RFE,要求他们改善错误报告,你将会得到一个粗陋的评论,而且这个RFE将迅速被关闭。这只是我的个人看法。
查看英文原文:JPA Frameworks Compared