现实世界中的ORM

Question

现实世界中的ORM

5

我正在开始一个新项目，我认为它将持续几年。我现在需要决定使用哪种ORM框架（或者是否使用ORM框架）。有经验的人能否告诉我ORM框架是否在实际应用中使用？我所担心的问题是：当我创建和修改实体时，ORM工具会为我生成表格和列等内容。然而，在项目上线并进入生产后，某些数据库更改将不可能进行。这会妨碍项目的进展吗？如果我像使用ibatis这样的框架，我知道只需要根据数据库更改调整SQL语句即可。有人能告诉我ORM工具是否在实际环境中存活下来了吗？在我的办公室，我们使用基于Java的ERP，它很久以前完成，并且从未使用过任何ORM框架。

问候。 Josh

- josh

4个回答

2

ORM在现实世界的应用中非常广泛。你提到的模式更改问题通常有两种处理方式：

1.如早期答案所建议的，您可以在数据库中手动维护模式，并使ORM更新其模式以匹配其在数据库中看到的内容。

2.您可以让ORM将数据库的模式与其自身对对象模型的信息进行比较并生成必要的查询以进行更新，如果有任何更改。

根据我的经验，任何像样的ORM都应该能够处理#1，大多数ORM似乎都能够管理#2，但这并不是普遍的。

至于哪个更好，那取决于您如何看待数据库和对象模型之间的关系。

如果您主要关注数据库，并使用ORM提供OO包装器来更轻松地访问表和字段，则可能需要选择＃1并完全控制数据库。

另一方面，如果您认为对象模型至高无上，并且主要使用数据库作为愚蠢的持久性机制，并且ORM用于简化此任务，则可能需要使用＃2，以便您可以专注于对象模型而无需担心底层数据库细节。或者您可能希望查看键/值存储，对象图持久性引擎或其他形式的NoSQL数据库，以获得更好的支持，以便轻松地进行对象持久性，而无需担心数据库端的模式更改。

- Dave Sherohman

谢谢，戴夫。我有几个想法要提出来。如果我按照你的第一种选项更改数据库，我必须更新我的映射元数据 - 注释或 XML。我更喜欢注释，这就意味着重编译和重新部署（版本变更，QA 流程等）。我想尽量避免这种情况。 - josh

1

我在生产中使用Hibernate + JPA已经有好几年了。虽然我从来没有依赖ORM模式生成，但我认为这是一个不好的实践，因为这样你不能完全控制模式，ORM也不会总是生成最优的模式。在我看来，使用像Liquibase这样的工具来跟踪模式迁移是一个更好的想法。

- Bozhidar Batsov

1

从领域驱动的角度来看，你不应该需要控制模式。事实上，你不应该关心你的领域模型如何表示为关系模式。 - Bozho

2

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

1

@Bozho，理论和实践很少能和平共处。我见过ORM中的错误导致生成不正确或非最优模式。此外，有些项目使用ORM仅针对特定的数据库，而客户坚持使用所有可能的数据库优化 - 这并不美观，但你知道他们说什么 - 客户永远是对的... - Bozhidar Batsov

Bozo，你说的是哲学，但在现实世界中，系统的每个部分都会被检查，包括模式！（这就像你说如果你做体育锻炼，你应该关心你的肌肉，而不需要关心你的胃一样） - darpet

0

我现在已经使用Hibernate几年了，非常满意它的表现。我只使用模式生成器来创建全新的数据库，但是对于升级，我使用人工编写的SQL脚本。

我认为自动化模式升级是不可靠的：例如，如果你想重命名一个字段，自动化工具会删除该字段并添加一个新的字段，从而导致数据丢失。

- Maurice Perry

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Lars Tackmann · Accepted Answer

只在早期开发和原型设计阶段使用自动生成的模式。生成的DDL几乎永远不会满足任何有经验的数据库管理员。此外，数据库通常比当前应用程序代码寿命更长，因此在其设计上花费时间通常是值得的。

选择一个灵活的映射器，并避免过于注重对象的映射器，因为这些映射器通常只支持有限的数据库自定义。Hibernate的存储过程集成不佳，JPAs缺乏对自定义类型映射器的支持也是如此。

像IBatis和EclipseLink这样的对象映射器是安全的选择，因为它们允许您映射几乎任何东西，确保您可以创建出优秀的领域模型和漂亮的模式设计。还要注意，Spring JDBC已经取得了很大的进展（特别是非常方便的SimpleJDBCTemplate），因此虽然从技术上讲它不是ORM，但它确实允许您做任何想做的事情，而无需编写繁琐的JDBC样板代码。