婚庆公司网站建设得多少钱,网站建设 中企动力北京,wordpress外国主题,南充营销型网站建设以下内容转载自#xff1a;https://segmentfault.com/a/1190000018472572
作者#xff1a;scherman
因为项目需要选择数据持久化框架#xff0c;看了一下主要几个流行的和不流行的框架#xff0c;对于复杂业务系统#xff0c;最终的结论是#xff0c;JOOQ是总体上最好的…以下内容转载自https://segmentfault.com/a/1190000018472572
作者scherman
因为项目需要选择数据持久化框架看了一下主要几个流行的和不流行的框架对于复杂业务系统最终的结论是JOOQ是总体上最好的可惜不是完全免费最终选择JDBC Template。
Hibernate和Mybatis是使用最多的两个主流框架而JOOQ、Ebean等小众框架则知道的人不多但也有很多独特的优点而JPA则是一组Java持久层Api的规范Spring Data JPA是JPA Repository的实现本来和Hibernate、Mybatis、JOOQ之类的框架不在同一个层次上但引入Spring Data JPA之类框架之后我们会直接使用JPA的API查询更新数据库就像我们使用Mybatis一样所以这里也把JPA和其他框架放在一起进行比较。
同样JDBC和其他框架也在同一层次位于所有持久框架的底层但我们有时候也会直接在项目中使用JDBC而Spring JDBC Template部分消除了使用JDBC的繁琐细节降低了使用成本使得我们更加愿意在项目中直接使用JDBC。
一、SQL封装和性能
在使用Hibernate的时候我们查询的是POJO实体类而不再是数据库的表例如hql语句 select count(*) from User里面的User是一个Java类而不是数据库表User。这符合ORM最初的理想ORM认为Java程序员使用OO的思维方式和关系数据库的思维方式差距巨大为了填补对象和关系思维方式的鸿沟必须做一个对象到关系的映射然后在Java的对象世界中程序员可以使用纯的对象的思维方式查询POJO对象查询条件是对象属性不再需要有任何表、字段等关系的概念这样java程序员就更容易做持久层的操作。
JPA可以视为Hibernate的儿子也继承了这个思路把SQL彻底封装起来让Java程序员看不到关系的概念用纯的面向对象思想重新创造一个新的查询语言代替sql比如hql还有JPQL等。支持JPA的框架例如Ebean都属于这种类型的框架。
但封装SQL使用另一种纯的面向对象查询语言代替sql真的能够让程序员更容易实现持久层操作吗MyBatis的流行证明了事实并非如此至少在大多数情况下使用hql并不比使用sql简单。首先从很多角度上看hql/JPQL等语言更加复杂和难以理解其次就是性能上明显降低速度更慢内存占用巨大而且还不好优化。最为恼火的是当关系的概念被替换为对象的概念之后查询语言的灵活性变得很差表达能力也比sql弱很多。写查询语句的时候受到各种各样的限制一个典型的例子就是多表关联查询。
不管是hibernate还是jpa表之间的连接查询被映射为实体类之间的关联关系这样如果两个实体类之间没有实现关联关系你就不能把两个实体或者表join起来查询。这是很恼火的事情因为我们很多时候并不需要显式定义两个实体类之间的关联关系就可以实现业务逻辑如果使用hql只是为了join我们就必须在两个实体类之间添加代码而且还不能逆向工程如果表里面没有定义外键约束的话逆向工程会把我们添加的关联代码抹掉。
MyBatis则是另外一种类型的持久化框架它没有封装SQL也没有创建一种新的面相对象的查询语言而是直接使用SQL作为查询语言只是把结果填入POJO对象而已。使用sql并不比hql和JPQL困难查询速度快可以灵活使用任意复杂的查询只要数据库支持。从SQL封装角度上看MyBatis比Hibernate和JPA成功SQL本不该被封装和隐藏让Java程序员使用SQL既不麻烦也更容易学习和上手这应该是MyBatis流行起来的重要原因。
轻量级持久层框架JOOQ也和MyBatis一样直接使用SQL作为查询语言比起MyBatisJOOQ虽然知名度要低得多但JOOQ不但和MyBatis一样可以利用SQL的灵活性和高效率通过逆向工程JOOQ还可以用Java代码来编写SQL语句利用IDE的代码自动补全功能自动提示表名和字段名减少程序员记忆负担还可以在元数据发生变化时发生编译错误提示程序员修改相应的SQL语句。
Ebean作为一种基于JPA的框架它也使用JPQL语言进行查询多数情况下会让人很恼火。但据说Ebean不排斥SQL可以直接用SQL查询也可以用类似JOOQ的DSL方式在代码中构造SQL语句还是JPQL语句但没用过Ebean所以具体细节不清楚。
JDBC Template就不用说了它根本没做ORM当然是纯SQL查询。利用Spring框架可以把JDBC Template和JPA结合起来使用在JPA不好查询的地方或者效率低不好优化的地方使用JDBC缓解了Hibernate/JPA封装SQL造成的麻烦但我仍没看到任何封装SQL的必要性除了给程序员带来一大堆麻烦和学习负担之外没有太明显的好处。
二、DSL和变化适应性
为了实现复杂的业务逻辑不论是用SQL还是hql或者JPQL我们都不得不写很多简单的或者复杂的查询语句ORM无法减少这部分工作最多是用另一种面向对象风格的语言去表达查询需求如前所述用面向对象风格的语言不见得比SQL更容易。通常业务系统中会有很多表每个表都有很多字段即便是编写最简单的查询语句也不是一件容易的事情需要记住数据库中有哪些表有哪些字段记住有哪些函数等。写查询语句很多时候成为一件头疼的事情。
QueryDSL、JOOQ、Ebean甚至MyBatis和JPA都设计一些特性帮助开发人员编写查询语句有人称之为“DSL风格数据库编程”。最早实现这类功能的可能是QueryDSL把数据库的表结构逆向工程为java的类然后可以让java程序员能够用java的语法构造出一个复杂的查询语句利用IDE的代码自动补全功能可以自动提示表名、字段名、查询语句的关键字等很成功的简化了查询语句的编写免除了程序员记忆各种名字、函数和关键字的负担。
QueryDSL有很多版本但用得多的是QueryDSL JPA可以帮助开发人员编写JPQL语句如前所述JPQL语句有很多局限不如SQL灵活高效。后来的JOOQ和Ebean基本上继承了QueryDSL的思路Ebean基本上还是JPA风格的ORM框架虽然也支持SQL但不清楚其DSL特性是否支持SQL语句编写在官网上看到的例子都是用于构造JPQL语句。
这里面最成功的应该是JOOQ和QueryDSL不同JOOQ的DSL编程是帮助开发人员编写SQL语句抛弃累赘的ORM概念JOOQ这个功能非常轻小非常容易学习和使用同时性能也非常好不像QueryDSL和Ebean需要了解复杂的JPA概念和各种奇异的限制JOOQ编写的就是普通的SQL语句只是把查询结果填充到实体类中严格说JOOQ没有实体类只是自动生成的Record对象JOOQ甚至不一定要把结果转换为实体类可以让开发人员按照字段取得结果的值相对于JDBCJOOQ会把结果值转换为合适的Java类型用起来比JDBC更简单。
传统主流的框架对DSL风格支持得很少Hibernate里面基本上没有看到有这方面的特性。MyBatis提供了SQL语句构建器来帮助开发人员构造SQL语句但和QueryDSL/JOOQ/Ebean差很多不能提示表名和字段名语法也显得累赘不像SQL。
JPA给人的印象是复杂难懂它的MetaModel Api继承了特点MetaModel APICriteria API再配合Hibernate JPA 2 Metamodel Generator让人有点QueryDSL JPA的感觉只是绕了一个大大的弯叠加了好几层技术最后勉强实现了QueryDSL JPA的简单易懂的功能。很多人不推荐JPAQueryDSL的用法而是推荐JPA MetaModel APICriteria APIHibernate JPA 2 Metamodel Generator的用法让人很难理解也许是因为这个方案是纯的标准的JPA方案。
数据库DSL编程的另一个主要卖点是变化适应性强数据库表结构在开发过程中通常会频繁发生变化传统的非DSL编程字段名只是一个字符串如果字段名或者类型改变之后查询语句没有相应修改编译不会出错也容易被开发人员忽略是bug的一个主要来源。DSL编程里面字段被逆向工程为一个java类的属性数据库结构改变之后作为java代码一部分的查询语句会发生编译错误提示开发人员进行修改可以减少大量bug减轻测试的负担提高软件的可靠性和质量。
三、跨数据库移植
Hibernate和JPA使用hql和JPQL这类数据库无关的中间语言描述查询可以在不同数据库中无缝移植移植到一个SQL有巨大差别的数据库通常不需要修改代码或者只需要修改很少的代码。Ebean如果不使用原生SQL而是使用JPA的方式开发也能在不同数据库中平滑的移植。
MyBatis和JOOQ直接使用SQL跨数据库移植时都难免要修改SQL语句。这方面MyBatis比较差只有一个动态SQL提供的特性对于不同的数据库编写不同的sql语句。
JOOQ虽然无法像Hibernate和JPA那样无缝移植但比MyBatis好很多。JOOQ的DSL很大一部分是通用的例如分页查询中Mysql的limit/offset关键字是很方便的描述方式但Oracle和SQLServer的SQL不支持如果我们用JOOQ的DSL的limit和offset方法构造SQL语句不修改移植到不支持limit/offset的Oracle和SQLServer上我们会发现这些语句还能正常使用因为JOOQ会把limit/offset转换成等价的目标数据库的SQL语句。JOOQ根据目标数据库转换SQL语句的特性使得在不同数据库之间移植的时候只需要修改很少的代码明显优于MyBatis。
JDBC Template应该最差只能尽量使用标准sql语句来减少移植工作量。
四、安全性
一般来说拼接查询语句都会有安全隐患容易被sql注入攻击。不论是jdbc还是hql/JPQL只要使用拼接的查询语句都是不安全的。对于JDBC来说使用参数化的sql语句代替拼接可以解决问题。而JPA则应该使用Criteria API解决这个问题。
对于JOOQ之类的DSL风格框架最终会被render为参数化的sql天生免疫sql注入攻击。Ebean也支持DSL方式编程也同样免疫sql注入攻击。
这是因为DSL风格编程参数化查询比拼接字符串查询更简单没人会拼接字符串。而jdbc/hql/JPQL拼接字符串有时候比参数化查询更简单特别是jdbc很多人会偷懒使用不安全的方式。
五、JOOQ的失败之处
可能大部分人会不同意虽然Hibernate、JPA仍然大行其道是最主流的持久化框架但其实这种封装SQL的纯正ORM已经过时效益低于使用它们的代价应该淘汰了。MyBatis虽然有很多优点但它的优点JOOQ基本上都有而且多数还更好。MyBatis最大的缺点是难以避免写xml文件xml文件编写困难容易出错还不容易查找错误。相对于JOOQMyBatis在多数情况下没有任何优势。
Ebean同时具有很多不同框架的优点但它是基于JPA的难免有JPA的各种限制这是致命的缺点。
JOOQ这个极端轻量级的框架技术上是最完美的突然有一天几个Web系统同时崩了最后发现是JOOQ试用期过期了这是JOOQ的失败之处它不是完全免费的只是对MySql之类的开源数据库免费。
最终我决定选择JDBC Template。 后记
不论我们是在做功能开发还是架构设计的时候框架的选型、中间的选型一直都是我们逃不开的话题任何一个框架、中间件它们都有各自的特点当这些特点放错了地方我们会吐槽说它“坑”。而每个东西之所有长期存在着是因为它还有其自身特点所能覆盖的应用场景。任何一个框架和中间件都不是解决问题的银弹我们不应该人云亦云而更应用根据自身团队的情况、业务需求的情况、成本预算的情况选择更适合自身环境的东西这样才是最好的。
