jSqlBox 4.0.8 发布,在 Java 里直接写 SQL 的 ORM 工具

2020年08月14日

jSqlBox主要特点是架构优、尺寸小、功能全,基本上所有与数据库操作相关的功能,jSqlBox都已提供。它的主要特点有:  
1.内核基于DbUtils并与之兼容。  
2.提倡在java里拼写SQL,独创参数内嵌式SQL写法, 而且任意CRUD方法里都可以混插SQl片段,例如:  
  new Demo().setName("张三").insert().putField("age", 15).update(" and name=?", param("李四"), " or age>? ",param(20));
3.只有单个1M大小的jar包,不依赖任何第三方库,不依赖Spring。  
4.支持分库分表、声明式事务、分布式事务,缓存翻译。  
5.支持80多种数据库方言,支持DDL生成、实体或数据库结构导出Excel,分页、函数变换、实体源码生成。  
6.学习成本低,兼容主要的实体JPA注解。 

在Java中直接写SQL是jSqlBox的主要特点之一,可能有人问XML或其它模板方式写SQL不香吗? 是的,用XML之类的模板有以下几个缺点:
1. 需要与插件配合才可以定位SQL,而且通常不支持SQL标记符的重构。 
2. XML中的占位符,在实际调用时是需要赋值的,这相当于又重复敲了一遍代码。很多人一看模板方式写SQL很简洁,但不要忘记了,模板是需要赋值的,赋值语句也是要占用源码行数的,一旦变量名变动,需要同时在模板和赋值语句两处修改。   
3. XML 之类的模板如果要写自定义函数很困难,而使用Java则没有这个问题。 
4. XML需要单独的文件存放,而且如果要在前端直接写SQL,则XML文件没法保存。(参见本人GoSqlGo项目)  

本次(jSqlBox4.0.8.jre8)更新内容:

把实体结构或数据库结构导出到Excel中

1.实体结构导出
以下语句会扫描指定包domain,把此包下的所有实体类的结构输出为Excel的CSV格式:

 TableModelUtils.entityPackage2Excel("com.abc.domain", "d:/packageOutput.csv");

也可以指定具体的实体类导出,如:

TableModelUtils.entity2Excel("d:/entitiesOutput.csv", User.class, Customer.class, Order.class);

以下为导出的Excel示例:
entityToExcelDemo

2.将数据库结构导出为Excel的CSV格式,第二个参数为方言类型:

@Autowired
DataSource ds;

TableModelUtils.db2Excel(ds.getConnection(), Dialect.MySQL57Dialect, "d:/dbOutput.csv");

以下是导出的Excel示例:
db2ExcelDemo

导出Excel功能目前只有固定的这几个方法。如果有不同格式、语言的导出需求,可以参照jSqlBox中的TableModelUtilsOfExcel.java源码写一个你自已的工具类即可,TableModelUtilsOfExcel.java这个工具类只有168行源码,相信在这个基础上你可以很快写出你想要的Excel输出工具来。

导出Excel有专用的工具或专门的项目,为什么jSqlBox要开发这个功能?不为别的,只因为jSqlBox能做到,从架构上jSqlBox内含了jDialects方言子项目,能轻而易举实现导出Excel这个功能,这个是早就有的打算,源码中早就注明了会有这个功能,不是为了跟风。 

展开阅读全文
20 收藏
分享
加载中
精彩评论
尺寸小首先说明它加载快,其次它反映了架构和源码质量,在实现等价功能的前提下,尺寸越小往往意味着架构更优、源码产生bug的机会更少、更新更慢、更易维护。比方说,jSqlBox内含的jBeanBox实现了与Spring类似的的IOC/AOP功能,只用了3000行源码。把软件写大了很容易,拼命加第三方包即可,但写小不容易,必须在功能和源码质量上做细心的取舍才能做到。
2020-08-14 23:48
2
举报
最新评论 (28)
这框架主要是方法命名上,看的让人没使用的欲望。希望后面版本能命名些通用而且大众的方法名
2020-08-16 08:57
0
回复
举报
据说计算科学中最难的两件事是命名和缓存失效,缓存失效我不懂,但这个命名真是难倒我这个命名渣了,每个命名都是我左挑右选定下来认为最合适的,然后你要我换其它更好的命名,想不出啊! 这样吧,源码都在这里了,有本事你把命名重构一下,只要有道理,我就批!
2020-08-16 09:11
0
回复
举报
直接在JAVA里有什么出奇,我一直这么玩
2020-08-15 23:27
0
回复
举报
如果不出意外,我玩的比你调皮:
```
DbContext ctx= new DbContext(dataSource);
ctx.iExecute("insert into users (", //
" name ,", param("Sam"), //一个参数写一行
notNull("age,", user.getAge()), //notNull方法的第二个参数为null时,这一项将不会添加到SQL中
" address ", param("Canada"), //
") ", valuesQuestions()); //自动根据参数个数补上 values(?,?...?)片段
ctx.iExecute("update users set name=?,address=?", param("Tom", "China"));//参数也可以连写
ctx.iExecute("delete from users where name=", ques("Tom"), " or address=", ques("China"));//参数混写,问号也可以省
new User(100, "Tom", "China").update(ctx2," and age>?", param(5), new PrintSqlHander(), IGNORE_EMPTY);//activeRecord也可混写SQL和其它乱七八糟的条目
```
最后一行做了以下事情:
手工切换到ctx2这个DbContext实例上(即操作另一个数据源)
主键userId=100的记录,如果age字段大于5则更新它的内容,且勿略实体的所有null或空值属性
打印SQL到控制台
2020-08-15 23:35
0
回复
举报
我觉得挺好的,很多人都陷入了spring的八股牢笼之中
2020-08-15 20:22
0
回复
举报
不是用不惯的问题,是公司项目没人敢用,这个东西其实挺好,不过细想还是不适合工程化要求高的项目,这是个让所有项目参与者重新习惯的问题。微服务用还挺合适的。
2020-08-15 18:34
0
回复
举报
说到点子上了,从后端角度看可能意义不大,最多只能干掉DAO层,所有业务在Service层就能完成[参见](https://gitee.com/xiandafu/dao-benchmark)。但要从大局看,工程化目标虽然不错,但制约开发效率的短板在哪? 前端,所有后端测试结果,还是需要前端一个个手工测,这已经谈不上工程化了。即然已经是手工测试了,干脆就把90%的普通CRUD和SQL也交给前端这个短板好了,还节省短板和非短板之间的交流成本,彻底干掉后端。这个jSqlBox是为了大前端时代简化学习和使用成本考虑的,并兼顾了高端需求。可以简单用几句话来形容它:
1.它是不支持容器、不支持懒加载的JPA
2.它兼容DbUtils
3.它独创并提倡SQL文本和参数混编的写法
第一个特点决定了它少坑易学。
第二个特点决定了它是强大的原生SQL工具。
第三个特点决定了它高效且可在前端直接使用。比如说下面是一个变形的SQL,写在前端javascript里,只有jSqlBox才能支持这种语法:
<script>
function getUserList(){
return $$Java(`
return DB.iQueryForMapList(
"select username, ", width(30), showAs("用户名(User name)"),
"age,", width(50), showAs("年龄(Age)"),
"address", width(50), showAs("地址(Address)"),
"from user_tb where username = ?", param($${usr.name}),
" or address like ?", param("%"+$$${usr.address}+"%")
`);
</script>
2020-08-15 20:08
0
回复
举报
前端留有操作 SQL 的口子,安全性就过不了吧。
2020-08-16 21:27
0
回复
举报
没问题的,开发时动态编泽,发布时象webpack一样用工具打包,把Java从Html中抽出来。
2020-08-16 22:51
0
回复
举报
首先感谢开源,支持作者,但是这个工具确实用处不大。java里面直接写sql在大部分公司就不符合规范,我个人感觉这样代码可读性也差一些,看看就好了。
2020-08-15 11:01
0
回复
举报
jdk13出来后,java里写sql应该一点没毛病。
2020-08-15 13:26
0
回复
举报
可以用Excel导入数据做单元测试吗?
2020-08-15 00:44
0
回复
举报
有打算将Excel表结构导入回Java,生成实体源码或DLL的开发打算,毕竟有导出功能还得想办法导回来。但暂时没有将Excel数据导入到数据库的打算。
因为导入数据的格式和具体业务相关,这个不应由通用DAO工具来做。通常应该自己写一个小工具类,根据具体的文本或Excel进行导入。或是直接加载SQL文件进行数据的插入准备。
2020-08-15 01:06
0
回复
举报
对于简单的单元测试数据准备,可以利用jSqlBox的forFields方法,把数据排好版放到Java源码里,参见下例的单元测试是如何准备测试数据的:
https://gitee.com/drinkjava2/jsqlbox/blob/master/core/src/test/java/com/github/drinkjava2/jsqlbox/function/entitynet/EntityNetTest.java
2020-08-15 01:13
0
回复
举报
启动半分钟就忍受不了? 那大型项目动不动 几百到G的包依赖,启动要多个集群配合才能起来的项目不得抓狂啊?
2020-08-14 22:33
0
回复
举报
我已经抓狂几百遍了。刚好前两天参与一个项目,Hibernate+Spring架构,每个Controller单元Mock测试都要先等15秒钟启动,每天要启动上百次吧,15x100=1500=25分钟就在让人抓狂的等待中度过了。15秒,什么概念?这么说吧,jSqlBox的200多个单元测试连建表带插入、删库用时7秒,可以把这200多个单元测试跑2遍了。
2020-08-14 22:48
0
回复
举报
单元测试 测试的一个类的 逻辑正确性,这个不需要启动整个应用。

针对一个 Controller 的启动 PowerMock 可以 mock 整个 servlet 容器。我做单侧时候测试一个 Controller 几十毫秒就完事了。

集成测试才需要启动整个项目,弱弱的问一句你单测时不会是每个 test case 都要重构整个容器吧?单测不是那么玩的。
2020-08-16 21:22
0
回复
举报
另外库也有 内存数据库可以使用, 单测时基本用不上删库吧?
2020-08-16 21:31
0
回复
举报
图省事,只做了controler的集成测试,因为集成测试覆盖了单元测试的功能,而且测完后连json接口文档都可以用日志生成了。用mockhttpservetrequest,没有启动容器,但就是启动太慢,改几行代码,就启动一次看看对不对,慢得受不了,按理说优化一下XML有可能加速Hibernate或Spring的启动,但又怕改出毛病,是别人的项目,我只打个帮手。
jSqlBox删库,更正一下,是删表,在内库数据库上跑,每个单元测试完会把自身的表删掉,因为同一个表名有可能被几个测试同时用到。不过前两天这个项目是在staging数据库备份上跑,只要注意删除生成的dummy数据就可以了。
2020-08-16 23:39
0
回复
举报
短小精悍😁😁😁
2020-08-14 19:38
0
回复
举报
确实小众,不解决痛点😂
2020-08-14 19:16
0
回复
举报
痛点就是mybaits和hibernate都有人用不惯,当hibernate+jdbc-shardings+springboot一套动不动十几M库依赖、半分钟启动时间谁能忍受? 十多年来各种DAO工具层出不穷就是最好的回答。jSqlBox希望是其中架构做的最好的,DbUtils天生就适合做为ORM工具的底层架构。将SQL文本和参数混写是jSqlBox推荐的做法和特色,这是其它ORM不具备的功能。但不表示它不支持模板啊,这是常规操作,甚至发明了Java8版的多行文本支持用来存放SQL,它自带简易模板并支持切换模板,你叫BeetlSql去切换模板试试?这是一个架构问题。
代码可读性是个问题,但相比与代码可维护性来说,可读性是次要的,代码(SQL也是代码)从来都是易写难读的,没有可维护性就不要空谈可读性。与其它ORM工具相比,jSqlBox通常总是完成相同功能所需写代码行数最少的,这就意味着生产效率。在可护充性上,如果一个SQL要求在取出字段的同时给它加上注解、列宽等等额外属性,目前只有jSqlBox这种SQL混写架构可以做到。
jSqlBox是小众不错,但总比整天冒出什么ORM工具强一点,但是如果有人想再发明DAO工具,先拿来和jSqlBox比一比功能和尺寸再说。
2020-08-14 22:16
0
回复
举报
我觉得尺寸不重要,关键还是要看功能,1M跟10M对现在的机器来说可以忽略
2020-08-14 22:36
0
回复
举报
尺寸小首先说明它加载快,其次它反映了架构和源码质量,在实现等价功能的前提下,尺寸越小往往意味着架构更优、源码产生bug的机会更少、更新更慢、更易维护。比方说,jSqlBox内含的jBeanBox实现了与Spring类似的的IOC/AOP功能,只用了3000行源码。把软件写大了很容易,拼命加第三方包即可,但写小不容易,必须在功能和源码质量上做细心的取舍才能做到。
2020-08-14 23:48
2
回复
举报
关键是代码可读性是个问题
2020-08-14 17:45
0
回复
举报
更多评论
28 评论
20 收藏
分享
在线直播报名
返回顶部
顶部