JPA框架比较

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