现实世界中的ORM

Posted 2023-04-12

【中文标题】现实世界中的ORM

【英文标题】：ORM in the realworld

【发布时间】：2010-04-20 08:45:58

【问题描述】：

我正在开始一个我认为会持续几年的新项目。我正在决定要使用的 ORM 框架（或者是否要使用一个）。任何有经验的人都可以告诉我 orm 框架是否用于现实世界的应用程序。我想到的问题是：当我创建和修改我的实体时，orm 工具将为我生成表和列等。但是，在项目上线并投入生产后，将无法更改某些数据库。这会不会阻碍项目的推进。例如，如果我使用了 ibatis 之类的框架，我知道我只需要根据数据库更改调整 sql 语句。有人可以告诉我 ORM 工具是否在实时环境中幸存下来。在我的办公室，我们使用基于 Java 的 ERP，这是很久以前完成的，但从未使用任何 ORM 框架完成。

问候。 乔什

【参考方案1】：

仅将自动生成的架构用于早期开发和原型设计。生成的 DDL 几乎永远不会满足任何有经验的 DBA。此外，数据库的寿命将比当前的应用程序代码更长，因此花时间在其设计上通常是值得的。

在选择映射器时，请选择灵活的映射器，并远离对象痴迷的映射器，因为这些映射器通常只支持有限的数据库自定义。 Hibernates 糟糕的存储过程集成浮现在脑海中，JPA 缺乏对自定义类型映射器的支持也是如此。

IBatis 和 EclipseLink 等对象映射器是安全的选择，因为它们允许您映射几乎任何东西，确保您可以创建出色的域模型和漂亮的架构设计.另请注意，Spring JDBC 已经走了很长一段路（尤其是非常方便的SimpleJDBCTemplate），因此虽然从技术上讲它不是 ORM，但它确实允许您做任何您想做的事情，而无需编写繁琐的 JDBC 样板代码.

【讨论】：

阐明为什么 ORM 框架不应该是“对象痴迷”，以及任何 ORM 框架如何允许您“重构数据库架构”。

一个好的 ORM 应该让 DBA 和应用程序开发人员都满意。我希望同时拥有出色的数据库设计和出色的对象模型。像 Hibernate 这样的映射器强制数据库设计以某种方式进行，我发现这非常有限。

这个被接受的答案表达了一个非常个人的观点，并没有说明对 ORM 附加值的一般看法以及何时使用它们。首先，ORM 应该是生成 SQL，支持存储过程只是一个工具。尽管如此，使用存储过程并不是 ORM 的理念（如果您正在使用存储过程，请不要使用 ORM）。其次，比较 Hibernate 和 iBATIS 就像比较苹果和橘子（更不用说 Spring JDBC），iBATIS 不是 ORM，它是一个数据映射器。但是，ORM 确实不适合深奥的模式。

【参考方案2】：

ORM 在实际应用中被广泛使用。您提到的架构更改问题通常通过以下两种方式之一处理：

正如之前的答案所建议的，您可以在数据库中手动维护架构，并让 ORM 更新其架构以匹配它在数据库中看到的内容。

您可以让 ORM 对照自己的对象模型信息检查数据库的架构，并生成必要的查询以在发生任何更改时进行更新。

根据我的经验，任何体面的 ORM 都应该能够处理 #1，并且大多数似乎都能够管理 #2，但它并不那么普遍。

至于哪个更好，嗯...这很大程度上取决于您如何看待数据库和对象模型之间的关系。

如果您的主要兴趣是数据库，并且您使用 ORM 围绕表和字段提供 OO 包装器以使它们更易于访问，那么您可能希望使用 #1 并完全控制数据库。

另一方面，如果您将对象模型视为至高无上的，并且主要将数据库用作一种愚蠢的持久性机制，而 ORM 用于简化该任务，那么您可能希望使用 #2 以便您可以专注于对象模型而不必担心底层数据库细节。或者，您可能想查看键/值存储、对象图持久性引擎或其他形式的 NoSQL 数据库，以便更好地支持直接的对象持久性，而无需担心数据库端的模式更改。

【讨论】：

谢谢戴夫。我有几个想法。如果我根据您的选项一更改数据库，我必须更新我的映射元数据 - 注释或 xml。我更喜欢注释，这意味着重新编译和重新部署。 （版本变更、QA 流程等）。我很想避免这种情况。

【参考方案3】：

我已经在生产中使用了几年的 Hibernate + JPA。不过，我从来没有依赖过 ORM 模式生成，而且我认为这通常是一种不好的做法，因为您不能以这种方式完全控制模式，并且 ORM 不会总是生成最佳模式。使用 Liquibase 之类的东西来跟踪架构迁移是一个更好的想法 IMO。

【讨论】：

从域驱动的角度来看，您不需要控制架构。事实上，您不应该关心您的域模型如何准确地表示为关系模式。

Bozho，在生产环境中，您关心您的域模型如何表示为关系数据库。一旦将应用程序投入生产，就不能再随意更改数据库。在大多数情况下，其他人将接管数据库。

@Bozho，理论与实践很少能和平共处。我似乎在 ORM 中存在错误，导致生成不正确或非最佳模式。还有一些项目使用仅针对特定数据库的 ORM，客户坚持使用所有可能的数据库优化 - 不漂亮，但你知道他们在说什么 - 客户永远是对的......

Bozo，你说的是哲学，在现实世界中，系统的每个部分都经过检查，包括模式！ （如果你说如果你做健身你应该关心你的贻贝，你不需要关心你的胃，这也是一样的）

【参考方案4】：

我已经使用 Hibernate 几年了，我对它非常满意。我使用模式生成器只是为了创建一个全新的数据库，但对于升级，我使用人造 sql 脚本。

我认为不可能可靠地自动升级架构：例如，如果您重命名一个字段，自动工具会删除该字段并添加一个新字段，从而丢失内容。