1

提供一些背景，

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

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

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

4

3 回答 3

5

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

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

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

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

祝你好运 ：-）

于 2012-07-13T07:54:30.967 回答
1

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

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

于 2012-07-13T13:20:42.790 回答
1

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

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

于 2012-07-12T19:01:55.837 回答