Java中的数据库持久性故事已经很久了，而且充满曲折：

• JDBC 是 每个人 最终用来与数据库对话的低级API 。但是，如果不使用更高级别的API，则您必须自己完成所有繁琐的工作（编写SQL查询，将结果映射到对象等）。

• EJB 1.0 CMP Entity Beans 是对更高级别的API的首次尝试，并且已被大型Java EE提供程序（BEA，IBM）成功采用，但未被用户采用。实体Bean太复杂且开销太大（理解，性能不佳）。 失败！

• EJB 2.0 CMP 试图通过引入本地接口来降低Entity Bean的某些复杂性，但是大多数复杂性仍然存在。EJB 2.0也缺乏可移植性（因为对象关系映射不是规范的一部分，因此部署描述符是专有的）。 失败！

• 然后是 JDO ，它 是 对象持久性的数据存储不可知标准（可以与RDBMS，OODBMS，XML，Excel，LDAP一起使用）。但是，尽管有几种开源实现，并且小型独立供应商采用了JDO（大多数OODBMS供应商希望JDO用户以后再从其RDBMS数据存储切换到OODBMS，但是显然这从未发生），但是它失败了被大型Java EE参与者和用户采用（因为编织是开发时的痛苦，并且使一些客户害怕奇怪的查询API，实际上太抽象了）。因此，尽管标准本身还没有失效，但我认为它是一个失败。 失败！

• 确实，尽管存在两个标准，但由于对象对关系数据库的持久性（标准之间的竞争，JDO的位置不明确，早期的失败），与EJB CMP和JDO相比，用户更喜欢使用诸如 Toplink ，旧播放器或 Hibernate之 类的专有API 。我相信CMP和不良行销是其中的一部分责任），而Hibernate实际上已成为该领域事实上的标准（这是一个很好的开源框架）。 成功！

• 然后，Sun意识到他们必须简化事情（并且通常是整个Java EE），并且他们使用 JPA （Java持久性API ）在Java EE 5中完成了该工作，它是EJB 3.0的一部分，是对象到关系数据库持久性的新标准。 。JPA统一了EJB 2 CMP，JDO，Hibernate和TopLink API /产品，并且似乎在EJB CMP和JDO失败（易于使用和采用）的地方成功了。 成功！

总而言之，Java的 数据库持久性 标准是 JPA， 并且应该优先于其他专有API（使用Hibernate的JPA实现很好，但使用JPA
API），除非您不需要ORM。与JDBC相比，它提供了更高级别的API，旨在节省您大量的手工工作（这是简化的方法，但仅此而已）。