jOOQ所应用的场合，使用价值以及开发本框架的原因

jOOQ的使用价值——对比JPA

Java和SQL已经有一定的历史，和取得很大的进步。 SQL这种语言已经"古老", 依旧一直投入使用的，且是便于理解的技术。 java也已经历史悠久，也是一项遗产。 尽管他的虚拟机允许很多新的，现代的语言可以基于虚拟机而构建。依旧，很多年过去了， 处理SQL和java之间的库接口出现和消失，留下JPA成为一种标准，带着一种怀疑感，也没有其他选择了。

到目前为止， 在其他语言中，能够重视SQL, 把SQL作为一等公民的数据库抽象层框架和几乎没有。很多的框架，包括企业标准的JPA, EJP, Hibernate, JOD, Critera Query, 以及其他框架都尝试隐藏SQL本身，把SQL的操作缩小到最小，例如JPQL，HQL，JDOOL和各式各样的其他查询语言。

jOOQ的出现，就是要填充这个缝隙——非常方便的操作，把SQL作为一等公民。

jOOQ的出现原因——与LINQ比较

其他平台， 参杂了一些想法， 例如LINQ（LINQ-to-SQL），或者Scala的SLICK，或Java的QueryDSL更好的把他们的一些查询概念集成到了各自的语言当中。 通过查询，他们明白了任意目标的查询，例如SQL，XML，集合和很多其他数据存储。 jOOQ声明，这也是一种错误的方式。

在更高级的查询使用用例（不紧急是简单的增删改查或者关联查询），人们希望从SQL的表现力上获利。 这归结于关系型SQL语言的自然表达力，这完全与面向对象和部分函数式语言不同，例如C#, Scala, 或者Java能够提供的。

按照传统的方式表达和校验连接，以及专门的为他们创造的数据表表达类型是非常难的。 当你想要支持更加先进的表表达方式是更加难的，例如汇总表，未嵌套的游标， 或仅仅是从继承表而来的任意的数据投射（projection）。如果使用强大的面向对象数据模型，这些特性似乎超出了这个范围。

本质上， 创建API，让他们看起来像SQL, 或者其中有部分像C#, Scala, Java的决策， 是一个明确的决定，而用来支持一个或其他平台。 然而，就像SLICK的进化, 作为LINQ以相似的方式去进化是较为容易的（或者java世界的QueryDSL）,SQL的特性范围，被非常清晰的去以当下的意图去与SQL数据库进行沟通交换信息在这些框架中是非常难的添加特性的（例如，如何对Oracle的分区外连接语法进行建模? 如何对ANSI/ISO SQL:1999分组集进行建模?如何支持标量子查询缓存?等）

jOOQ的出现就是为了填充这个缝隙。

jOOQ的出现原因——与SQL/JDBC比较

为什么不直接使用SQL? 不行吗？

SQL能够被以文本的方式写入并传递给JDBC的API。这些年过去了，人们开始对这样的应用程序变得越来越谨慎和小心翼翼，这归结于很多原因：

• 并无类型安全
• 无安全语法
• 无绑定之对于索引安全
• 冗长的SQL字符串连接
• 对于索引技术，非常令人厌烦的绑定值
• 处理JDBC冗余的源和异常处理。
• 一个“状态性的”， 不是完全面向对象的JDBC API， 是很难用的

很多原因，在过去， 其他框架也尝试以一种或多种的方式抽象JDBC。不幸的是， 很多也完全抽象了SQL。

JOOQ的出现也是填充这个缝隙。

jOOQ是有所不同的

SQL不是针对业务模型抽象的，SQL被限定在繁重的映射器的狭窄边界中， 隐藏了关系型数据库的美妙和简易性。SQL从来都不是面向对象的。 SQL除过SQL本身，就是SQL, 除此之外没有别的。

如下为jOOQ的学习大纲的思维导图：drawOn