写点什么

JPA 框架比较

  • 2008-01-16
  • 本文字数:1745 字

    阅读完需:约 6 分钟

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

2008-01-16 01:3917144
用户头像

发布了 150 篇内容, 共 45.6 次阅读, 收获喜欢 10 次。

关注

评论

发布
暂无评论
发现更多内容

TiDB 集群的可用性详解及 TiKV Label 规划

TiDB 社区干货传送门

TiDB 底层架构

5.0 新特性试用体验之 Clustered Index

TiDB 社区干货传送门

实践案例 TiDB 底层架构 版本测评 新版本/特性发布 性能测评

【TiDB 最佳实践系列】TiDB 高并发写入常见热点问题及规避方法

TiDB 社区干货传送门

实践案例

JQ 入门教程

TiDB 社区干货传送门

TiDB 底层架构

2 年成本节省 73%,京东物流在云数据库上的选择和实战

TiDB 社区干货传送门

实践案例

使用pd-recover 恢复pd 多数节点故障的场景

TiDB 社区干货传送门

管理与运维 故障排查/诊断

【文章】精选实践汇总2

TiDB 社区干货传送门

实践案例

端到端的实时计算:TiDB + Flink 最佳实践

TiDB 社区干货传送门

实践案例

写冲突场景下的悲观/乐观事务模型选择

TiDB 社区干货传送门

实践案例

TiDB升级5.x连接问题

TiDB 社区干货传送门

故障排查/诊断

raft:分布式一致性算法笔记

TiDB 社区干货传送门

TiDB 底层架构

数据库选型中的非技术因素

TiDB 社区干货传送门

数据库架构选型

【文章】精选实践汇总1

TiDB 社区干货传送门

实践案例

【TiDB 最佳实践系列】开发 Java 应用使用 TiDB 的最佳实践

TiDB 社区干货传送门

实践案例

使用 TiDB 构建实时应用

TiDB 社区干货传送门

实践案例

多种方式告诉你如何计算DM同步数据到TiDB的延时时间

TiDB 社区干货传送门

管理与运维

cdc 同步到 s3 的故障

TiDB 社区干货传送门

迁移 管理与运维 故障排查/诊断 新版本/特性发布

PD模块梳理

TiDB 社区干货传送门

TiDB 底层架构

大教堂终将倒下,但集市永存

TiDB 社区干货传送门

实践案例 数据库架构选型

如何在 TiDB 上高效运行序列号生成服务

TiDB 社区干货传送门

管理与运维

实时 AP、分库分表、大数据应用,TiDB 在虎牙直播是怎么用的?

TiDB 社区干货传送门

实践案例

关于 TiDB 性能优化的一些思考

TiDB 社区干货传送门

性能调优

TiDB 优化之消失的统计信息

TiDB 社区干货传送门

实践案例

Chaos Mesh 助力 Apache APISIX 提升稳定性

TiDB 社区干货传送门

实践案例

某业务升级5.0解决慢SQL问题

TiDB 社区干货传送门

实践案例 故障排查/诊断

Weir:原生 TiDB 支持的数据库中间件

TiDB 社区干货传送门

实践案例

TiDB实例间数据同步之TiCDC实践

TiDB 社区干货传送门

实践案例

通过 BR 完成不同 K8s 的 TiDB 集群的数据恢复

TiDB 社区干货传送门

故障排查/诊断

一次热点问题排查经历

TiDB 社区干货传送门

故障排查/诊断

TiDB 多Socket 服务器性能扩展问题分析

TiDB 社区干货传送门

性能调优 性能测评

TUG 技术大咖圆桌讨论:如何评判一个数据架构的好坏

TiDB 社区干货传送门

数据库架构选型

JPA框架比较_Java_James Kao_InfoQ精选文章