你喜欢什么Java ORM，为什么？
这是一个相当开放的问题。 我将开始一个新的项目，并正在寻找不同的ORM与数据库访问集成。
你有什么最爱？ 你有没有build议保持清醒？
我已经停止使用ORM。
理由不是这个概念有很大的缺陷。 hibernate效果很好。 相反，我发现查询的开销很低，我可以将大量复杂的逻辑应用到大型的SQL查询中，并将大量的处理转移到数据库中。
所以考虑只使用JDBC包。
没有，因为拥有一个ORM需要太多的控制，而且带来很小的好处。 当您必须debugging使用ORM导致的exception时，节省的时间很容易被吹走。 此外，ORM不鼓励开发人员学习SQL，以及关系数据库是如何工作的，以及如何利用这些好处。
许多ORM很棒，你需要知道为什么要在JDBC之上添加抽象。 我可以推荐http://www.jooq.org给你（免责声明：我是jOOQ的创造者，所以这个答案是有偏见的）。; jOOQ拥抱以下模式：
- SQL是一件好事。 很多东西在SQL中可以很好地expression出来。 不需要完全抽象SQL。
- 关系数据模型是一件好事。 它已被certificate是过去40年来最好的数据模型。 不需要XML数据库或真正面向对象的数据模型。 相反，您的公司运行Oracle，MySQL，MSSQL，DB2或任何其他RDBMS的几个实例。
- SQL有一个结构和语法。 不应该使用JDBC中的“低级”string连接来表示 – 或者HQL中的“高级”string连接 – 这两者都容易出现语法错误。
- 处理主要查询时，variables绑定往往非常复杂。 这是应该被抽象的东西。
- 在编写处理数据库数据的Java代码时，POJO非常棒。
- POJO是一个手动编写和维护的痛苦。 代码生成是要走的路。 您将拥有包括数据types安全性的编译安全查询。
- 数据库首先。 尽pipe数据库之上的应用程序可能会随着时间而改变，但是数据库本身可能会持续更长的时间。
- 是的，您的旧数据库中有存储过程和用户定义的types（UDT）。 你的数据库工具应该支持。
还有很多其他的好ORM的。 特别是Hibernate或者iBATIS有一个很好的社区。 但是，如果你正在寻找一个直观的，简单的，我会说给你一个尝试。 你会爱上它！ 🙂
看看这个例子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); 而如何在jOOQ中expression：
// 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))))));
Hibernate，因为它基本上是Java中的事实标准，并且是创buildJPA的驱动力之一。 在Spring中得到了很好的支持，几乎所有的Java框架都支持它。 最后，GORM是一个非常酷的包装，它使用Groovy来dynamic查找等等。
它甚至被移植到.NET（NHibernate），所以你也可以在那里使用它。
hibernate，因为它：
- 是稳定的 – 这么多年来，它没有任何重大问题
- 决定了ORM领域的标准
- 执行标准（JPA），除了口述。
- 在因特网上有大量的信息。 有很多教程，常见的问题解决scheme等
- function强大 – 您可以将非常复杂的对象模型转换为关系模型。
- 它支持任何主要和中等RDBMS
- 一旦你学习得很好 ，很容易
关于为什么（以及何时）使用ORM的几点意见：
- 你使用系统中的对象（如果你的系统devise的很好）。 即使使用JDBC，您最终也会创build一些翻译层，以便将数据传输到对象。 但我的下注是hibernate比任何定制的解决scheme更好的翻译。
- 它不会剥夺你的控制权。 你可以用非常小的细节来控制事物，如果API没有一些远程function – 执行一个本地查询，你就可以拥有它。
- 任何中等规模或更大的系统都不能承受一吨的查询（在一个地方或分散），如果它的目的是可维护的
- 如果性能不重要。 Hibernate增加了性能开销，在某些情况下这是不能被忽略的。
我会build议使用MyBatis 。 它是一个在JDBC之上的薄层，将对象映射到表格并且仍然使用普通的SQL非常容易，一切都在你的控制之下。
在编写中等规模的JavaSE应用程序时，我对Avaje Ebean有了非常好的经验。
它使用标准的JPA注释来定义实体，但公开一个更简单的API（没有EntityManager或任何附加/分离的实体废话）。 它还允许您在必要时轻松使用SQL查询或事件普通JDBC调用。
它也有一个非常好的stream体和types安全的查询API。 你可以写下如下的东西：
List<Person> boys = Ebean.find(Person.class) .where() .eq("gender", "M") .le("age", 18) .orderBy("firstName") .findList();
SimpleORM ，因为它是直接的，没有魔法。 它定义了Java代码中的所有元数据结构，并且非常灵活。
SimpleORM通过将关系数据库中的数据映射到内存中的Java对象来提供与Hibernate类似的function。 查询可以通过Java对象来指定，对象标识与数据库关键字alignment，对象之间的关系得到维护，修改后的对象通过乐观锁自动刷新到数据库。
但与Hibernate不同的是，SimpleORM使用了一个非常简单的对象结构和体系结构，避免了复杂的parsing，字节码处理等的需要。SimpleORM小而透明，包装在两个只有79K和52K的jar子里，只有一个小的和可选的依赖（Slf4j）。 （Hibernate超过2400K加上大约2000K依赖Jars）。这使得SimpleORM易于理解，从而大大降低了技术风险。
Eclipse Link有很多原因，但是我觉得它比其他主stream解决scheme的膨胀率要低（至less不要那么臃肿）。
哦，Eclipse Link已经被选为JPA 2.0的参考实现
虽然我分享了关于Java自由格式SQL查询replace问题的担忧，但我确实认为批评ORM的人是因为通常很差的应用程序devise而这样做的。
真正的OOD是由类和关系驱动的，ORM为你提供了不同关系types和对象的一致映射。 如果您使用ORM工具，并以ORM框架支持的任何查询语言（包括但不限于Javaexpression式树，查询方法，OQL等）完成编码查询expression式，那么您肯定是做了错误的事，即您的类模型很可能不能以应有的方式支持你的要求。 干净的应用程序devise并不需要在应用程序级别进行查询。 我已经重构了许多项目，人们开始使用ORM框架的方式与他们用于在其代码中embeddedSQLstring常量的方式相同，最后每个人都惊讶于整个应用程序一旦匹配就会变得简单和可维护使用使用模型build立你的类模型。 当然，对于searchfunction等等，你需要一个查询语言，但是即使这样，查询也受到很大的限制，创build一个复杂的VIEW并将其映射到只读持久化类比build立expression式更好维护和查看在你的应用程序的代码中的一些查询语言。 VIEW方法还利用数据库function，通过实现，可以比Java源代码中的任何手写SQL更好地实现性能。 所以，我不认为任何不平凡的应用程序不使用ORM的任何理由。
