jOOQ 项目存在的原因
以下段落摘自 jOOQ用户手册的前言部分。值得思考的是,为什么你应该(或者不应该)在某特定项目中使用JOOQ。具体讲,你可能正要从jOOQ 和JPA,或者jOOQ和Hibernate,或者jOOQ和QueryDSL、或者jOOQ和SLICK(对Scala而言)的两者之中选择其一。这里给出一些指导原则(当然会稍微有点偏向JOOQ):
jOOQ存在的理由 —— 同JPA相比
Java和SQL在一起使用已经有很久了。SQL是一种很“古老”但很完备的技术,大家对它的理解也已很透彻。虽然在Java的运行平台JVM之上也能建立一些新式的当代语言,但Java语言可也不算新了。然后,经过了这么多年,处理SQL和Java二者之间接口的库(Library)不断变来变去,只留下了JPA这个大家勉强在半信半疑中接受的一个标准, 几乎没留下任何别的选项。
迄今为止,能够真正把SQL看做编程语言当中具有首要地位的数据库抽象框架或库,少之又少。包括业界标准JPA, EJB、Hibernate、JDO、Criteria Query以及其它很多在内的框架,为将SQL的使用范围缩减到最小采用了JPQL、HQL、JDOQL以及其它各种各样的低级查询语言,它们都是在企图隐藏SQL本身。
jOOQ来填补这一空白。
jOOQ存在的理由 —— 同LINQ相比
为了更好地将查询作为一个概念集成到编程语言当中,其它的平台采用了LINQ (同LINQ-to-SQL一起), Scala用的是SLICK,Java也采用了QueryDSL。通过查询,它们可以理解对任意目标的查询,这些目标可以是SQL、XML、集合(Collection)以及其它的异构数据存储(Data Store)。JOOQ断言,这样也是走错了方向。
在比较高级的查询用例中(比简单的CRUD和少量的多表查询高级),人们还是希望能够从SQL较强的表达能力中获益。SQL本身的关系型特质,使得它和C#、Scala或者Java等等这类面向对象语言和非完全函数式编程语言能够做到的事情相比,差别巨大。
要用形式化的方式表达和验证它们产生的多表查询和临时表(ad-hoc)的表达式的类型非常困难。要想支持类似数据透视表(Pivot Table)、非巢套式游标(Unnested Cursor)或者仅仅是从派生表中进行任意投射(Projection)等等这样高级的表表达式,那就更加是难上加难了。如何在非常强的面向对象类型模型之中实现这些特性,不太可能会在考虑范围之内。
本质上讲, 决定创建看上去跟SQL或者C#或者Scala、Java很像的API,就是一种确定无疑的或者偏向这个或者偏向那个平台的决定。尽管让SLICK以和LINQ(或者Java世界里的QueryDSL)类似的方式进行演进比较容易, 但是随后,用以清晰表达其背后意图的SQL特性范围(Feature Scope)就很难再添加进来了(比如,你怎么来对Oracle的分区外联语法进行建模?如何对ANSI/ISO SQL:1999中的分组集(Grouping Set)进行建模?怎样才能支持标量子查询缓存?等等问题)。
jOOQ来填补这个空白。
jOOQ很不同
SQL从来就不是一种抽象的语言。它不局限在重量级的映射器这样狭小的范围之内,也不隐藏关系型数据的美以及简单性。SQL一直都不面向对象。SQL从来就不是SQL之外的任何其它东西!
相关文章
- Java要抛弃祖宗的基业,Java程序员危险了!
- 十大 Java 语言特性
- JVM 三色标记算法,原来是这么回事!
- 聊聊 Spring 事务控制策略以及 @Transactional 失效问题避坑
- 写给 Java 程序员的前端 Promise 教程
- 写给 Java 程序员的前端 Promise 教程,你学会了吗?
- Java 中为什么不全部使用 Static 方法?
- Java 池化技术你了解多少?
- Java 服务 Docker 容器化优秀实践
- Spring Boot + EasyExcel导入导出,简直太好用了!
- 我们一起聊聊 Java 内存泄漏
- CentOS 下安装 Docker 极简教程
- JDK 19 功能集冻结:Java 19 只有七个新特性
- 关于 CMS 垃圾回收器,你真的懂了吗?
- 为什么会有这么多编程语言?
- 改善Java代码的八个建议
- 接口流量突增,如何做好性能优化?
- Java 以编程方式创建JAR文件
- POJO、Java Bean是如何定义的
- Spring 的 Bean 明明设置了 Scope 为 Prototype,为什么还是只能获取到单例对象?