您是否为大型应用程序推荐JDBC或JPA？

Question

提供一些背景知识，

1. 我们有相当大的架构，包含数百个具有复杂关系的表。
2. 数据量也很大，数据的性质相对敏感（财务）
3. 当前架构是 - Java EE：调用存储过程的会话Bean，DAO（JDBC）。
4. 在数据库级别，我们有一些复制机制，可以将数据保存在与前端和后端数据库（托管在不同的盒子上）的sych中。因此，应用程序需要从前端数据库中查找（读取）数据，如果不可用则查看后端数据库。因此，在JPA术语中，我们可能需要两个不同的EntityManagers实例。

随着系统的不断发展，可扩展性和性能是最大的问题。

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

Answer 1

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

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

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

3）花一些时间阅读Hibernate书籍和文档。真。大多数时候人们抱怨Hibernate，这是因为他们真的不知道幕后发生了什么。

祝你好运： - ）

Answer 2

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

我建议您的高级团队花一些时间在您做其他任何事情之前，先从至少一些最有希望的替代品中学习一些例子。

Answer 3

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

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