对于大型应用程序，您推荐 JDBC 还是 JPA？答案

【问题标题】：Do you recommend JDBC or JPA for large applications?对于大型应用程序，您推荐 JDBC 还是 JPA？
【发布时间】：2012-07-12 14:36:23
【问题描述】：

提供一些背景，

我们有相当大的架构，由数百个具有复杂关系的表组成。
数据量也很大，数据的性质相对敏感（财务）
当前架构是 - Java EE：会话 Bean、DAO (JDBC) 调用存储过程。
在数据库级别，我们有一些复制机制来保持数据与前端和后端数据库同步（托管在不同的机器上）。因此，应用程序将需要从前端数据库中查找（读取）数据，如果不可用，则在后端数据库中查找。因此，在 JPA 术语中，我们可能需要两个不同的 EntityManager 实例。

随着系统仍在增长，可扩展性和性能是最大的问题。

根据上述信息，是否有人对迁移应用程序以使用 JPA 等持久性框架的可行性有任何意见？在上述情况下，持久性框架面临哪些挑战？

【问题讨论】：

不是“EntityManager 的两个不同实例”而是“两个持久性单元”
我的建议：对于一个如此庞大且（似乎）至关重要的系统，不要去互联网上寻求建议。聘请一些有经验的顾问。

标签： hibernate jpa orm jdbc

【解决方案1】：

我的经验是，一旦你浏览了几页，你就会得到某种框架。这可以像交换数据映射一样简单，但是对于 Java，使用类型安全的愿望可能会导致某种形式的映射框架。 Hibernate，通过它的 JPA 注释，是迄今为止 Java 世界中最著名的，但当然还有其他实现。我对 Grails 也有过很好的体验，它实际上在底层使用了 Hibernate（默认情况下），但当然这是一个完整的堆栈。

我建议您的高级团队在做任何其他事情之前花一些时间从至少一些最有希望的替代方案中研究一些示例。

【讨论】：

【解决方案2】：

我同意 @SJuan76 的观点，即您应该让某人深入了解您的架构以提供更好的建议。但无论如何，这里有一些提示：

1) 从映射开始。以“正确的 OOP 方式”映射您的实体，并尝试通过调整映射来达到您拥有的相同架构。如果关系那么复杂，您可能会遇到一些障碍，最好在映射阶段处理它（而不是仅映射一小部分，对于 PoC）。

2) 不要担心 Hibernate 的性能。 Hibernate 可能会比任何内部 JDBC 框架更快。但是，如果您决定将业务逻辑从存储过程移至 Java 代码，请查看性能变化。在转换它们时，您可能需要转换思维方式，因为在 SP 中处理大量数据通常比将大量数据传输到应用层并在那里处理要快。

3) 一定要花一些时间阅读 Hibernate 书籍和文档。真的。大多数时候人们抱怨 Hibernate 是因为他们并不真正了解幕后发生的事情。

祝你好运:-)

【讨论】：

【解决方案3】：

你提到你有存储过程，那么会有一个问题，你想重新实现你的大部分项目。

如果你不想这样，那么忘记 JPA 或 Hibernate，在这种情况下，我建议你使用 MyBatis（或 iBatis）。

【讨论】：