您更喜欢哪种 Java ORM，为什么？

What Java ORM do you prefer, and why?

提问by

It's a pretty open ended question. I'll be starting out a new project and am looking at different ORMs to integrate with database access.

这是一个非常开放的问题。我将开始一个新项目，并正在研究不同的 ORM 以与数据库访问集成。

Do you have any favorites? Are there any you would advise staying clear of?

你有什么最喜欢的吗？你有什么建议远离吗？

回答by Abdullah Jibaly

Hibernate, because it's basically the defacto standard in Java and was one of the driving forces in the creation of the JPA. It's got excellent support in Spring, and almost every Java framework supports it. Finally, GORM is a really cool wrapper around it doing dynamic finders and so on using Groovy.

Hibernate，因为它基本上是 Java 中的事实上的标准，并且是创建 JPA 的驱动力之一。它在 Spring 中得到了很好的支持，几乎每个 Java 框架都支持它。最后，GORM 是一个非常酷的包装器，可以使用 Groovy 执行动态查找器等。

It's even been ported to .NET (NHibernate) so you can use it there too.

它甚至已被移植到 .NET (NHibernate)，因此您也可以在那里使用它。

回答by David Schmitt

SimpleORM, because it is straight-forward and no-magic. It defines all meta data structures in Java code and is very flexible.

SimpleORM，因为它是直接的并且没有魔法。它在 Java 代码中定义了所有元数据结构，并且非常灵活。

SimpleORM provides similar functionality to Hibernate by mapping data in a relational database to Java objects in memory. Queries can be specified in terms of Java objects, object identity is aligned with database keys, relationships between objects are maintained and modified objects are automatically flushed to the database with optimistic locks.

But unlike Hibernate, SimpleORM uses a very simple object structure and architecture that avoids the need for complex parsing, byte code processing etc. SimpleORM is small and transparent, packaged in two jars of just 79K and 52K in size, with only one small and optional dependency (Slf4j). (Hibernate is over 2400K plus about 2000K of dependent Jars.) This makes SimpleORM easy to understand and so greatly reduces technical risk.

SimpleORM 通过将关系数据库中的数据映射到内存中的 Java 对象来提供与 Hibernate 类似的功能。可以根据 Java 对象指定查询，对象标识与数据库键对齐，对象之间的关系得到维护，修改后的对象使用乐观锁自动刷新到数据库。

但与 Hibernate 不同的是，SimpleORM 使用了非常简单的对象结构和架构，避免了复杂的解析、字节码处理等。 SimpleORM 小巧透明，封装在两个 jar 中，大小只有 79K 和 52K，只有一个小且可选依赖（Slf4j）。（Hibernate 超过 2400K 加上大约 2000K 的依赖 Jars。）这使得 SimpleORM 易于理解，因此大大降低了技术风险。

回答by Tom Neyland

Eclipse Link, for many reasons, but notably I feel like it has less bloat than other main stream solutions (at least less in-your-face bloat).

Eclipse Link，出于多种原因，但值得注意的是，我觉得它比其他主流解决方案的膨胀更少（至少减少了面对面的膨胀）。

Oh and Eclipse Link has been chosen to be the reference implementation for JPA 2.0

哦，Eclipse Link 已被选为 JPA 2.0 的参考实现

回答by David Crawshaw

I have stopped using ORMs.

我已经停止使用 ORM。

The reason is not any great flaw in the concept. Hibernate works well. Instead, I have found that queries have low overhead and I can fit lots of complex logic into large SQL queries, and shift a lot of my processing into the database.

原因不是概念上的任何重大缺陷。休眠运行良好。相反，我发现查询的开销很低，我可以将大量复杂的逻辑放入大型 SQL 查询中，并将我的大量处理转移到数据库中。

So consider just using the JDBC package.

所以考虑只使用 JDBC 包。

回答by simon

None, because having an ORM takes too much control away with small benefits. The time savings gained are easily blown away when you have to debug abnormalities resulting from the use of the ORM. Furthermore, ORMs discourage developers from learning SQL and how relational databases work and using this for their benefit.

没有，因为有一个 ORM 会带走太多的控制，而好处很小。当您必须调试因使用 ORM 导致的异常时，所节省的时间很容易被浪费掉。此外，ORM 不鼓励开发人员学习 SQL 以及关系数据库的工作原理，并将其用于他们的利益。

回答by IgKh

I had a really good experience with Avaje Ebeanwhen I was writing a medium sized JavaSE application.

在编写中型 JavaSE 应用程序时，我对Avaje Ebean 的体验非常好。

It uses standard JPA annotations to define entities, but exposes a much simpler API (No EntityManager or any of that attached/detached entities crap). It also lets you easily use SQL queries or event plain JDBC calls when necessary.

它使用标准的 JPA 注释来定义实体，但公开了一个更简单的 API（没有 EntityManager 或任何附加/分离的实体废话）。它还允许您在必要时轻松使用 SQL 查询或事件普通 JDBC 调用。

It also has a very nice fluid and type-safe API for queries. You can write things like:

它还具有用于查询的非常流畅且类型安全的 API。你可以写这样的东西：

List<Person> boys = Ebean.find(Person.class)
                                  .where()
                                       .eq("gender", "M")
                                       .le("age", 18)
                                  .orderBy("firstName")
                                  .findList();

回答by Bozho

Hibernate, because it:

休眠，因为它：

• is stable - being around for so many years, it lacks any major problems
• dictates the standards in the ORM field
• implements the standard (JPA), in addition to dictating it.
• has tons of information about it on the Internet. There are many tutorials, common problem solutions, etc
• is powerful - you can translate a very complex object model into a relational model.
• it has support for any major and medium RDBMS
• is easy to work with, once you learn it well

• 稳定 - 存在这么多年，没有任何重大问题
• 规定了 ORM 领域的标准
• 除了口述它之外，还实现了标准 (JPA)。
• 互联网上有大量关于它的信息。教程很多，常见问题解决方法等
• 功能强大 - 您可以将非常复杂的对象模型转换为关系模型。
• 它支持任何主要和中型 RDBMS
• 很容易使用，一旦你学好了

A few points on why (and when) to use ORM:

关于为什么（以及何时）使用 ORM 的几点：

• you work with objects in your system (if your system has been designed well). Even if using JDBC, you will end up making some translation layer, so that you transfer your data to your objects. But my bets are that hibernate is better at translation than any custom-made solution.
• it doesn't deprive you of control. You can control things in very small details, and if the API doesn't have some remote feature - execute a native query and you have it.
• any medium-sized or bigger system can't afford having one ton of queries (be it at one place or scattered across), if it aims to be maintainable
• if performance isn't critical. Hibernate adds performance overhead, which in some cases can't be ignored.

• 您使用系统中的对象（如果您的系统设计良好）。即使使用 JDBC，您最终也会制作一些转换层，以便您将数据传输到您的对象。但我敢打赌，hibernate 比任何定制解决方案更擅长翻译。
• 它不会剥夺您的控制权。您可以控制非常小的细节，如果 API 没有某些远程功能 - 执行本机查询，您就拥有它。
• 任何中型或大型系统都无法承受大量查询（无论是在一个地方还是分散在一个地方），如果它旨在可维护
• 如果性能不重要。Hibernate 增加了性能开销，在某些情况下不能忽略。

回答by adrian.tarau

I would recommend using MyBatis. It is a thin layer on top of JDBC, it is very easy to map objects to tables and still use plain SQL, everything is under your control.

我会推荐使用MyBatis。它是 JDBC 之上的一个薄层，很容易将对象映射到表并且仍然使用纯 SQL，一切都在您的控制之下。

回答by Lukas Eder

Many ORM's are great, you need to know why you want to add abstraction on top of JDBC. I can recommend http://www.jooq.orgto you (disclaimer: I'm the creator of jOOQ, so this answer is biased). jOOQ embraces the following paradigm:

许多 ORM 都很棒，您需要知道为什么要在 JDBC 之上添加抽象。我可以向你推荐http://www.jooq.org（免责声明：我是 jOOQ 的创造者，所以这个答案是有偏见的）。jOOQ 包含以下范例：

• SQL is a good thing. Many things can be expressed quite nicely in SQL. There is no need for complete abstraction of SQL.
• The relational data model is a good thing. It has proven the best data model for the last 40 years. There is no need for XML databases or truly object oriented data models. Instead, your company runs several instances of Oracle, MySQL, MSSQL, DB2 or any other RDBMS.
• SQL has a structure and syntax. It should not be expressed using "low-level" String concatenation in JDBC - or "high-level" String concatenation in HQL - both of which are prone to hold syntax errors.
• Variable binding tends to be very complex when dealing with major queries. THAT is something that should be abstracted.
• POJO's are great when writing Java code manipulating database data.
• POJO's are a pain to write and maintain manually. Code generation is the way to go. You will have compile-safe queries including datatype-safety.
• The database comes first. While the application on top of your database may change over time, the database itself is probably going to last longer.
• Yes, you do have stored procedures and user defined types (UDT's) in your legacy database. Your database-tool should support that.

• SQL 是个好东西。许多事情可以用 SQL 很好地表达。不需要完全抽象 SQL。
• 关系数据模型是个好东西。它已被证明是过去 40 年来最好的数据模型。不需要 XML 数据库或真正面向对象的数据模型。相反，您的公司运行 Oracle、MySQL、MSSQL、DB2 或任何其他 RDBMS 的多个实例。
• SQL 具有结构和语法。它不应该使用 JDBC 中的“低级”字符串连接或 HQL 中的“高级”字符串连接来表示——两者都容易出现语法错误。
• 在处理主要查询时，变量绑定往往非常复杂。那是应该抽象的东西。
• POJO 在编写操作数据库数据的 Java 代码时非常有用。
• 手动编写和维护 POJO 很痛苦。代码生成是要走的路。您将拥有编译安全的查询，包括数据类型安全。
• 数据库是第一位的。虽然数据库顶部的应用程序可能会随着时间的推移而改变，但数据库本身可能会持续更长时间。
• 是的，您的旧数据库中确实有存储过程和用户​​定义类型 (UDT)。您的数据库工具应该支持这一点。

There are many other good ORM's. Especially Hibernate or iBATIS have a great community. But if you're looking for an intuitive, simple one, I'll say give jOOQ a try. You'll love it! :-)

还有许多其他好的 ORM。特别是 Hibernate 或 iBATIS 有一个很棒的社区。但是，如果您正在寻找一种直观、简单的方法，我会说试一试 jOOQ。你会喜欢的！:-)

Check out this example SQL:

查看此示例 SQL：

  // Select authors with books that are sold out
  SELECT * 
    FROM T_AUTHOR a
   WHERE EXISTS (SELECT 1
                   FROM T_BOOK
                  WHERE T_BOOK.STATUS = 'SOLD OUT'
                    AND T_BOOK.AUTHOR_ID = a.ID);

And how it can be expressed in jOOQ:

以及它如何在 jOOQ 中表达：

  // Alias the author table
  TAuthor a = T_AUTHOR.as("a");

  // Use the aliased table in the select statement
  create.selectFrom(a)
        .whereExists(create.selectOne()
                           .from(T_BOOK)
                           .where(T_BOOK.STATUS.equal(TBookStatus.SOLD_OUT)
                           .and(T_BOOK.AUTHOR_ID.equal(a.ID))))));

回答by Mirko Klemm

While I share the concerns regarding Java replacements for free-form SQL queries, I really do think people criticizing ORM are doing so because of a generally poor application design.

虽然我对 Java 替换自由格式 SQL 查询表示担忧，但我确实认为批评 ORM 的人之所以这样做，是因为应用程序设计通常很糟糕。

True OOD is driven by classes and relationships, and ORM gives you consistent mapping of different relationship types and objects. If you use an ORM tool and end up coding query expressions in whatever query language the ORM framework supports (including, but not limited to Java expression trees, query methods, OQL etc.), you are definitely doing something wrong, i.e. your class model most likely doesn't support your requirements in the way it should. A clean application design doesn't really need queries on the application level. I've been refactoring many projects people started out using an ORM framework in the same way as they were used to embed SQL string constants in their code, and in the end everyone was suprised about how simple and maintainable the whole application gets once you match up your class model with the usage model. Granted, for things like search functionality etc. you need a query language, but even then queries are so much constrained that creating an even complex VIEW and mapping that to a read-only persistent class is much nicer to maintain and look at than building expressions in some query language in the code of your application. The VIEW approach also leverages database capabilities and, via materialization, can be much better performance-wise than any hand-written SQL in your Java source. So, I don't see any reason for a non-trivial application NOT to use ORM.

真正的 OOD 是由类和关系驱动的，ORM 为您提供了不同关系类型和对象的一致映射。如果您使用 ORM 工具并最终以 ORM 框架支持的任何查询语言（包括但不限于 Java 表达式树、查询方法、OQL 等）编写查询表达式，那么您肯定做错了什么，即您的类模型很可能不以应有的方式支持您的要求。干净的应用程序设计并不真正需要应用程序级别的查询。我一直在重构许多项目，人们开始使用 ORM 框架的方式与他们习惯将 SQL 字符串常量嵌入代码中的方式相同，最终每个人都惊讶于一旦匹配，整个应用程序变得如此简单和可维护使用使用模型提升您的类模型。当然，对于搜索功能等，您需要一种查询语言，但即便如此，查询仍然受到很大限制，以至于创建一个更复杂的 VIEW 并将其映射到只读持久类比构建表达式更易于维护和查看在您的应用程序代码中使用某种查询语言。VIEW 方法还利用了数据库功能，并且通过物化，可以比 Java 源代码中的任何手写 SQL 具有更好的性能。所以，我看不出有任何不重要的应用程序不使用 ORM 的理由。但即便如此，查询仍然受到如此多的限制，以至于创建一个更复杂的 VIEW 并将其映射到只读持久类比在应用程序代码中使用某种查询语言构建表达式要好得多。VIEW 方法还利用了数据库功能，并且通过物化，可以比 Java 源代码中的任何手写 SQL 具有更好的性能。所以，我看不出有任何不重要的应用程序不使用 ORM 的理由。但即便如此，查询仍然受到如此多的限制，以至于创建一个更复杂的 VIEW 并将其映射到只读持久类比在应用程序代码中使用某种查询语言构建表达式要好得多。VIEW 方法还利用了数据库功能，并且通过物化，可以比 Java 源代码中的任何手写 SQL 具有更好的性能。所以，我看不出有任何不重要的应用程序不使用 ORM 的理由。