jOOQ与Hibernate：何时选择哪个

Hibernate已成为Java生态系统中的事实上的标准，事实上，如果标准对您很重要，并且如果您将JCP与ISO，ANSI，IEEE等置于同一级别，那么Hibernate也是实际的JavaEE标准实现。

本文的目的不是讨论标准，而是讨论愿景。 Hibernate赞同JPA对ORM的看法。 jOOQ拥有SQL强大查询的愿景，因此，为了争辩，让我们像jOOQ / JDBC / SQL一样互换使用Hibernate / JPA / ORM。

为什么现在不应该使用Hibernate的问题总是经常出现 -正是因为Hibernate是事实上的标准，并且是许多其他框架（例如Grails（使用GORM，又使用Hibernate ））中的第一个框架选择。

但是，即使是Hibernate的创建者Gavin King，也不相信Hibernate应该用于所有方面 ：

加文·金

如果是这样，您是否可以考虑任何客观的决策帮助点，何时使用ORM以及何时使用SQL？

高水平的讨论

首先，让我们将讨论提高到更高的水平。与其在Hibernate和jOOQ之间确定它们各自域的具体实现，不如考虑ORM与SQL以及它们的不同用例。

在确定ORM（例如Hibernate）和SQL（例如jOOQ）之间时，您应该问自己的驱动问题不是项目复杂性问题。我们一些最苛刻的客户正在对具有数千个表/视图的中型架构使用jOOQ。通常，这些模式被高度标准化，有时甚至部署在多达六个不同的RDBMS上。 jOOQ专为在这些情况下工作而设计，同时也牢记了简单的用例。

因此，与其考虑项目的复杂性，不如问自己以下问题：

您的数据模型将驱动您的应用程序设计，还是您的应用程序设计将驱动您的数据模型？
这里的一个主要方面是从数据库是否可以在应用程序中生存下来的角度来考虑您是否“关心”数据库的问题。很多时候，应用程序来来往往。它们可能会用Python / JavaScript等进行重写，直到5年后。或者，您有多个应用程序访问同一个数据库：Java应用程序，一些Perl脚本，存储过程等。在这种情况下，数据库设计是您项目中的优先事项，而jOOQ在这些设置中工作得非常好。从某种意义上说，您不一定要“关心”您的数据库，而只是想在某个地方“持久化”您的Java域，而这恰好是一个关系数据库，那么Hibernate也许是一个更好的选择-至少在项目的早期阶段，因为您可以轻松地从Entity模型生成数据库架构。
您将主要从事复杂的阅读和简单的写作，还是从事复杂的写作？
当阅读很复杂时，SQL才真正发挥作用。当您联接许多表时，当您在数据库中聚合数据时，当您进行报告时，当您进行批量读取和写入时。您是从集合论的角度来考虑数据的，例如您的数据整体。但是，用SQL编写CRUD很无聊。这就是为什么jOOQ还为您提供了一个ActiveRecord风格的API，该API在处理单个表时会处理无聊的部分（Jason提到过）。但是，如果您的编写变得复杂，即您必须加载一个复杂的对象图，其中包含20个涉及内存的实体，对其进行乐观锁定，以多种不同方式对其进行修改，然后再次将其持久保存，那么SQL / jOOQ将无济于事。这就是Hibernate最初创建的目的。

意见

我相信数据是永远的。您应该*始终*假定数据库在应用程序中仍然存在。重写应用程序（的一部分）比迁移数据库要容易得多。拥有一个干净且设计良好的数据库架构将始终使项目，特别是复杂项目的收益得到回报。另请参阅我们先前有关“无模式”数据库的谬误的文章。

而且，大多数项目实际上完成90％的读取和10％的写入，写入通常并不复杂（在事务中修改2-3个表）。这意味着大多数情况下，不需要Hibernate / JPA的一级和二级缓存解决的复杂性。人们常常会误解这些功能，而只是关闭缓存，将Hibernate的缓存一直刷新到服务器，从而以错误的方式使用Hibernate。

但是，如果您不确定上述两个决策轴，则可以走中间路线，仅将jOOQ用于报告，批处理等，并将Hibernate用于CRUD –在CQRS（命令查询职责隔离）中： http://martinfowler.com/bliki/CQRS.html ）样式。也有很多jOOQ用户选择了此路径。