将Java EE与jOOQ结合使用的初学者指南

Java EE附带了自己的持久性API：JPA。当您想要将RDBMS实体（表/关系）映射到Java实体（类）时，JPA最强大，主要遵循1：1映射策略。其背后的想法是，业务逻辑通常并不像关系代数或SQL那样真正面向集合，而是面向记录的，这意味着将业务规则和业务逻辑应用于单个记录。

换句话说，当SQL和关系代数与值（元组）有关时，JPA与（单个记录的）身份和状态有关。这就是JPA的亮点，因为：

寿命太短，无法使用SQL编写CRUD

但是正如加文·金（Gavin King）经常说的那样：

加文·金冬眠

RDBMS不仅仅与CRUD有关

加文·金（Gavin King）在开始研究最流行的JPA实现Hibernate时就已经意识到了OLAP的炒作。商业智能或当今称为数据科学的技术比简单的CRUD依赖更高级的功能-简单的JPA规范或其实现从未将其作为目标。

实际上，您不必一定要执行OLAP才能从本机SQL中受益，在更普通的OLTP环境中也会出现更简单的用例，例如

报告中
批量和批量数据处理
查询复杂的业务规则

尽管JPA提供了JPQL和Criteria API，这将帮助您在查询中表达一定数量的复杂性，但最终您将受到这些语言和API提供的功能的限制，正如Michael Simons最近在有趣的Criteria API与jOOQ比较中所记录的那样。

因此，所有JPA实现都提供了一种使用“本地SQL”查询数据库的方法。在先前的博客文章中，我们展示了如何利用jOOQ的类型安全DSL API通过JPA的本机查询API运行SQL查询，然后获取结果……

……作为管理实体
…作为使用SqlResultSetMapping映射的DTO

在上述情况下，jOOQ仅用作SQL查询构建器，而查询执行则留给JPA。

在Java EE中使用jOOQ进行所有数据库查询

记住jOOQ的理念：

jOOQ本质上是类型安全的JDBC。而已。

即使可以使用JPA执行本机SQL，也不必这样做。您可以直接在JDBC级别上进行操作，这是JPA经常需要执行的操作，例如在工作时…

……具有特定于供应商的数据类型
……使用非平凡的存储过程
…与语句批处理
…带有可更新的游标

在应用程序服务器上运行应用程序时，可以选择所需和需要的功能，其余部分则使用专有的API（例如在JDBC之上运行的jOOQ）。例如，您可以使用：

用于会话和范围管理的EJB
CDI用于依赖项注入
jOOQ与您的数据库交互

（您也可以将JTA添加到堆栈中-为简单起见，我们暂时将其跳过）

该过程很简单：只需使用CDI将javax.sql.DataSource注入到会话bean中即可：

@Stateless
public class LibraryEJB {@Resource(lookup="java:data-source-configuration")private DataSource ds;
}

…并开始使用JDBC进行操作：

public List<Author> fetchAuthors() 
throws SQLException {List<Author> result = new ArrayList<>();// Get a Connection from the injected DataSourcetry(Connection con = ds.getConnection();PreparedStatement stmt = con.prepareStatement("SELECT * FROM AUTHOR ORDER BY ID");ResultSet rs = stmt.executeQuery()) {result.add(new Author(rs.getInt("ID"),rs.getString("FIRST_NAME"),rs.getString("LAST_NAME")));}return result;
}

…或使用jOOQ：

public Result<AuthorRecord> fetchAuthors() {// Pass the injected DataSource to jOOQreturn DSL.using(ds, H2).selectFrom(AUTHOR).orderBy(AUTHOR.ID).fetch();
}

请注意，jOOQ （默认情况下）如何将所有结果急切地获取到内存中，并急切地关闭诸如JDBC Connection ， PreparedStatement和ResultSet类的资源，这样就无需您自己去处理资源管理的麻烦。

再次：