ORM在现实世界中

Question

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

的问候。 约什

Answer 1

仅使用自动生成的模式进行早期开发和原型设计。生成的DDL几乎永远不会满足任何有经验的DBA。此外，数据库正常运行的时间比当前应用程序代码长，所以花在设计上的时间通常是值得的。

当选择一个映射器时，请选择一个灵活的映射器并远离那些痴迷于对象的映射器，因为这些映射器通常只支持有限的数据库定制。我想到了休眠不良的存储过程集成，JPA缺乏对自定义类型映射器的支持。

像 IBatis 和 EclipseLink 这样的对象映射器是安全的选择，因为它们允许您映射几乎任何内容，确保您可以创建一个伟大的域模型和一个漂亮的架构设计。还要注意 Spring JDBC 已经走了很长的路（特别是非常方便的SimpleJDBCTemplate），所以虽然技术上不是ORM但它确实允许你做任何你想做的事而不用编写繁琐的JDBC样板代码。

Answer 2

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

1. 如前面的答案所示，您可以在数据库中手动维护架构，并让ORM更新其架构以匹配它在数据库中看到的架构。

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

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

至于哪个更好，那么......这在很大程度上取决于你如何查看数据库与对象模型之间的关系。

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

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

Answer 3

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

Answer 4

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

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