现实世界中的ORM

Question

我正在开始一个新的项目，我认为这个项目将持续几年。我正在决定使用哪个ORM框架(或者是否使用一个)。有经验的人能告诉我orm框架是否用在现实世界的应用程序中吗？我考虑的问题是:当我创建和修改实体时，orm工具将为我生成表和列等。但是，在项目上线并投入生产后，某些数据库更改将是不可能的。这是否会阻碍项目的推进。例如，如果我使用了像ibatis这样的框架，我知道我只需要根据数据库的变化来调整sql语句。有人能告诉我ORM工具是否在实时环境中存活下来了吗？在我的办公室，我们使用的是基于java的ERP，这是很久以前做的，从来没有使用过任何ORM框架。

致以问候。乔希

Answer 1

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

在选择映射器时，选择一个灵活的映射器，并远离那些痴迷于对象的映射器，因为这些映射器通常只支持有限的数据库定制。考虑到Hibernates糟糕的存储过程集成，JPA缺乏对自定义类型映射器的支持。

像IBatis和EclipseLink这样的对象映射器是安全的选择，因为它们允许您映射几乎任何内容，确保您可以创建出色的域模型和漂亮的模式设计。还要注意的是，JDBC已经走过了很长的路(特别是非常方便的SimpleJDBCTemplate)，所以虽然从技术上讲它不是一个，但它确实允许您在不编写繁琐的样板代码的情况下做任何您想做的事情。

Answer 2

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

1. 正如前面的答案所建议的，您可以在数据库中手动维护架构，并让对象关系管理更新其架构以匹配它在数据库中看到的内容。
2. 您可以让对象关系管理根据其自身有关对象模型的信息检查数据库的架构，并在发生任何更改时生成必要的查询进行更新。

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

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

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

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

Answer 3

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