1

我总是看到更多的 Java Web 应用程序使用 ORM 框架将实体映射到数据库，并且显然使对象的序列化更容易。

这看起来不错，通常涉及很多代码，例如：

@Entity
@Table(name="Flight")
public class Flight implements Serializable {
    Long id;

    @Id
    public Long getId() { return id; }

    public void setId(Long id) { this.id = id; }
}

上面将 Flight POJO 映射到名为 Flight 的数据库表，这对于从头开始设计的新应用程序来说似乎很合理。

但是，当必须使用遗留表和逻辑开发应用程序时，使用 JPA 之类的 ORM 解决方案是否可行？

换句话说，可以同时使用 ORM 表和遗留表吗？如何将遗留表映射到 POJO？

我见过类似的问题，比如遗留表到 jpa2 实体并从数据库生成对象 @entities但是他们都在谈论将表“逆向工程”到对象的工具。不应该有一个选项可以手动完成，一旦正确映射，让 ORM 框架管理它们？这一切似乎都是我所要求的黑客行为，但是在我看来，将遗留数据库转换为 ORM 管理的数据库应该是规则。

谢谢

4

3 回答 3

0

从不同的角度来看：越来越多的 Web 应用程序不再使用“直接 SQL”。这扩大了 Web 开发人员和 SQL/RDBMS 之间的“距离”。它创造了一个差距。

甚至还有一些库朝着相反的方向发展：不再有 HQL，只有简单的 SQL。例如，有ANORM，这意味着“Anorm 不是对象关系映射器”。

给定的例子看起来很简单。但整个故事不仅仅是表定义和插入/更新/删除。稍后您必须查询您的数据，并且您可能希望使用数据库的所有功能（窗口聚合函数等）尽可能快地查询它，此时 ORM 可能会很棘手。

至于你的问题：我建议仔细检查当前的数据模型和查询。编写一些原型来查看访问数据的两种方式是否/如何共存（缓存问题、集成问题等）。如果您不能完全切换到 ORM 映射器，那么坚持使用“普通旧 SQL”可能会更容易，这没关系。重要的不是映射器：归根结底，到达您的 SQL 服务器的是SQL 命令。

并确保您可以使用最新版本的 JPA。早期版本之一甚至没有区分大小写的排序功能。一般来说，由于版本通常由您的数据中心定义（=您别无选择），请检查此版本是否支持您需要的所有功能。

于 2013-05-26T15:26:18.917 回答
0

术语非 ORM 数据库是不正确的，数据库可能是关系型（RDBMS）、面向对象、面向文档等...... ORM 表示对象关系映射，它仅指一种旨在简化 RDBMS 使用的框架面向对象的语言。

您可以完美地结合使用 JPA 和本机 sql 来查询数据库，您甚至可以使用 JPA 工具轻松地从数据库模式中生成所有数据库实体。

但

您必须仔细注意这些事实：

  • ORM 将作为 java 实体管理数据库的内存中投影状态，托管实体的集合由对象“EntityManager”（或休眠中的 Session）管理。该对象不会知道使用本机 sql 进行的操作，无论是程序中的操作还是数据库中的操作（最终触发器或存储过程）。您的实体的状态可能与数据库不一致。您可以手动刷新实体状态，但您必须关心它。

  • 您应该使用 JPA api 执行本机查询以利用底层数据源连接池。如果你真的需要它，你可以使用本机 JDBC 语句（我真的不明白为什么），但你也应该对同一个数据源执行它。在这种情况下，如果使用容器管理的 entityManager，您将无法利用事务上下文传播（您将使用自己的 sql 连接进行本机 sql 查询）

    • 于 2013-05-24T22:26:18.120 回答
    0

    是的，您可以将 ORM 用于现有数据库。我不知道这些天 JPA 有多灵活（没有保留所有规范更改），但我知道 Hibernate在将对象与现有表匹配时非常灵活（支持各种遗留配置）。没有什么能阻止您并排使用 ORM 和直接 JDBC（如果您通过两个渠道管理更新，可能会出现一些同步问题）。事实上，对于某些场景，直接使用 JDBC 可能是有意义的（例如，即席报告）。同样，我不确定所有 JPA 提供了什么，但我知道休眠会话允许您访问底层 JDBC 连接，以便您可以在需要时运行本机 SQL。

    于 2013-05-24T18:27:23.893 回答