现实世界中的 ORM
我正在开始一个新项目，我认为该项目将持续几年。我即将决定使用哪个 ORM 框架（或者是否使用一个框架）。有经验的人可以告诉我orm框架是否在现实应用程序中使用。我想到的问题是：当我创建和修改实体时，orm 工具将为我生成表和列等。但是，在项目上线并投入生产后，某些数据库更改将无法进行。这是否会阻碍项目的进展。例如，如果我使用像 ibatis 这样的框架，我知道我只需要根据数据库更改调整 sql 语句。有人可以告诉我 ORM 工具是否在实际环境中幸存下来。在我的办公室，我们使用很久以前就完成的基于java的ERP，并且从未使用任何ORM框架完成。
问候。 乔什
I am begining a new project that i think will last for some years. Am in the point of deciding the ORM framework to use (or whether to use one at all). Can anyone with experience tell me whether orm frameworks are used in realworld applications. The problem i have in mind is this: The orm tool will generate for me tables and columns etc as i create and modify my entities. However, after the project has gone live and is in production, certain database changes will not be possible. Can this hinder the advancement of the project. If i had used a framework like ibatis for example, i know i would only need to adjust the sql statements based on the database changes. Can someone tell me whether ORM tools have survived the live environment. At my office, we use java based ERP that was done long ago and it was never done using any ORM framework.
Regards.
Josh
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
仅使用自动生成的模式进行早期开发和原型设计。生成的 DDL 几乎永远无法满足任何有经验的 DBA。此外，数据库的寿命将比当前应用程序代码的寿命更长，因此花时间进行设计通常是值得的。
选择映射器时，请选择灵活的映射器，并远离痴迷于对象的映射器，因为这些映射器通常仅支持有限的数据库自定义。 Hibernate 糟糕的存储过程集成浮现在脑海中，就像 JPA 缺乏对自定义类型映射器的支持一样。
像 IBatis 和 EclipseLink 这样的对象映射器是安全的选择，因为它们允许您映射几乎任何内容，确保您可以创建出色的域模型和漂亮的架构设计。另请注意，Spring JDBC 已经取得了很大的进步（特别是非常方便的 SimpleJDBCTemplate），因此虽然从技术上讲它不是 ORM，但它确实允许您做任何您想做的事情，而无需编写繁琐的 JDBC 样板代码。
Only use auto generated schema's for the early development and prototyping. The generated DDL will almost never satisfy any experienced DBA. Further the database is properly going to live longer than the current application code, so spending time on its design is usually well worth the effort.
When choosing a mapper go for a flexible one and stay clear of the object-obsessed mappers, since these often only supports limited database customization. Hibernates poor stored procedure integration comes to mind, as does JPAs lack of support for custom type mappers.
Object mappers like IBatis and EclipseLink are safe choices as they allows you to map almost anything, ensuring that you can create both a great domain model and a nifty schema design. Also note that Spring JDBC has come a very long way (in particular the very handy SimpleJDBCTemplate), so while technically not a ORM it does allow you to do anything you want without writing tedious JDBC boilerplate code.
ORM 在实际应用中应用非常广泛。您提到的架构更改问题通常通过以下两种方式之一处理：
正如前面的答案所建议的，您可以在数据库中手动维护架构，并让 ORM 更新其架构以匹配它在数据库中看到的内容。
您可以让 ORM 根据其自己的有关对象模型的信息检查数据库的架构，并生成必要的查询以在发生任何更改时进行更新。
根据我的经验，任何像样的 ORM 都应该能够处理#1，并且大多数似乎能够管理#2，但它并不那么通用。
至于哪个更好，嗯...这在很大程度上取决于您如何看待数据库和对象模型之间的关系。
如果您的主要兴趣是数据库，并且您使用 ORM 为表和字段提供 OO 包装器，以便更轻松地访问它们，那么您可能会选择#1 并保持对数据库的完全控制。
另一方面，如果您将对象模型视为至高无上，并且主要使用数据库作为愚蠢的持久性机制，并使用 ORM 来简化该任务，那么您可能会想要使用#2，这样您就可以专注于对象模型，而不必担心底层数据库细节。或者，您可能想看看键/值存储、对象图持久性引擎或其他形式的 NoSQL 数据库，以便更好地支持简单的对象持久性，而根本不必担心数据库端的架构更改。
ORMs are used very widely in real-world applications. The schema change issue you mentioned is typically dealt with in one of two ways:
As suggested by earlier answers, you can maintain the schema manually in the database and have the ORM update its schema to match what it sees in the database.
You can have the ORM check the database's schema against its own information about the object model and generate the necessary queries to update if there have been any changes.
In my experience, any decent ORM should be able to handle #1 and most seem to be able to manage #2, but it's not quite as universal.
As for which is better, well... That depends a lot on how you view the relationship between your database and your object model.
If your primary interest is on the database and you use an ORM to provide an OO wrapper around the tables and fields to make them accessible more easily, then you'll probably want to go with #1 and keep full control over the database.
If, on the other hand, you view the object model as supreme and are primarily using the database as a dumb persistence mechanism, with the ORM serving to simplify that task, then you'll probably want to use #2 so you can focus on the object model and not have to worry about the underlying database details. Or you might want to take a look at key/value stores, object-graph persistence engines, or other forms of NoSQL databases in order to get better support for straightforward object persistence without having to worry about schema changes on the database side at all.
我已经在生产中使用 Hibernate + JPA 多年了。不过，我从未依赖过 ORM 模式生成，并且我认为这通常是不好的做法，因为您无法完全控制这种模式，并且 ORM 并不总是生成最佳模式。在我看来，使用 Liquibase 之类的东西来跟踪架构迁移是一个更好的主意。
I have used for several years in production Hibernate + JPA. I have never relied on the ORM schema generation though and I think that this is bad practice in general since you're not totally in control of the schema this way and ORM will not always generate the optimal schema. Using something like Liquibase for tracking schema migrations in a much better idea IMO.
我已经使用 Hibernate 几年了，我对它非常满意。我仅使用架构生成器来创建全新的数据库，但对于升级，我使用人造 SQL 脚本。
我认为不可能可靠地自动升级模式：例如，如果您重命名一个字段，自动工具将删除该字段并添加一个新字段，从而丢失内容。
I have been using Hibernate for a few years now, and I am very happy with it. I use the schema generator only to create a brand new database, but for upgrades, I use man-made sql scripts.
I don't think it is possible to reliabily automate the upgrade of the schema: if you rename a field for instance, an automatic tool would remove the field and add a new one, thereby losing content.