FastSQL 1.1.1 发布,基于spring-jdbc 的简单 ORM 框架 - 开源中国社区
Float_left Icon_close
FastSQL 1.1.1 发布,基于spring-jdbc 的简单 ORM 框架
chenjazz 2018年03月26日

FastSQL 1.1.1 发布,基于spring-jdbc 的简单 ORM 框架

chenjazz chenjazz 发布于2018年03月26日 收藏 15 评论 9

FastSQL一个基于spring-jdbc 的简单 ORM 框架,它支持 sql 构建、sql 执行、命名参数绑定、查询结果自动映射和通用 DAO。结合了 Hibernate/JPA 快速开发和 Mybatis 高效执行的优点。

FastSQL 可以完全满足你控制欲,可以用 Java 代码清晰又方便地写出 sql 语句并执行。

FastSQL已发布到maven中央仓库。

如果使用 Maven 来构建项目,则需将下面的 dependency 代码置于 pom.xml 文件中:

<dependency>
    <groupId>top.fastsql</groupId>
    <artifactId>fastsql</artifactId>
    <version>1.1.1</version>
</dependency>

如果使用 Gradle 来构建项目,则需将下面的代码置于 build.gradle 文件的 dependencies 代码块中:

compile 'top.fastsql:fastsql:1.0.0'

构建 SQLFactory

你可以直接从 Java 程序构建一个 SQLFactory ,如果使用SQL的执行功能,至少需要设置 DataSource 。

//新建一个DataSource(这里使用了Spring-Jdbc的SimpleDriverDataSource) DataSource dataSource = new SimpleDriverDataSource([传入url,username等]); SQLFactory sqlFactory = new SQLFactory();
sqlFactory.setDataSource(dataSource);

从 SQLFactory 中获取 SQL

既然有了 SQLFactory ,我们就可以从中获得 SQL 的实例了。SQL类完全包含了面向数据库执行 sql 命令所需的所有方法。 你可以通过 SQL 实例来构建并直接执行 SQL 语句。例如:

SQL sql = sqlFactory.createSQL(); Student student = sql.SELECT("*").FROM("student").WHERE("id=101").queryOne(Student.class);

示例

使用beanParameter方法支持传入一个参数bean

public class StudentDTO{ private String name; private int age; //省略set和get方法 }

StudentDTO dto =new StudentDTO();
dto.setName="小明";
dto.setAge=10;

sqlFactory.createSQL().SELECT("*") .FROM("student") .WHERE("name=:name")           .AND("age>:age")
     .beanParameter(dto).queryList(StudVO.class);

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:FastSQL 1.1.1 发布,基于spring-jdbc 的简单 ORM 框架
分享
评论(9)
精彩评论
4
数据库持久层开发涉及的方面比较多,通常要考虑这些方面:跨数据库的分页、是否支持DDL、是否支持模板及是否可切换模板、是否自行开发事务或兼容Spring事务、多数据源支持、对象映射、对象关联查询、实体Bean注解、主键生成方案、是否提供ActiveRecord模式、是否提供SqlMapper模式、是否可以在代码里直接调用SQL,是否有可能写出支持重构的SQL功能、是否尺寸小、易学习、依赖库少、是否有1+N这个坑以及解决方案、是否支持多行SQL文本, 是否可以不用XML,是否是个独立的持久层工具......, 等等。
另外文档的完备、源码本身质量、项目的成熟度和普及度也很重要。
目前Java界各种持久层工具层出不穷,正是因为目前各个持久层工具都不能完全达到上述所有要求,所以总是有人想要发明更新的工具,通常有两种模式:在现有工具上作二次开发,或是从头全部自已开发。这两方面的代表举两个例子分别是MyBatis-Plus和BeetlSql。在现有工具上作二次开发,优点是只需要补上缺少的功能即可,缺点是继承了原工具的缺陷,如MyBatis-Plus必须支持繁琐的XML,还有你这个插件只能用于Spring环境中。从头开发的优点是可以获得一个比较优良的架构,缺点是工作量大,不能利用现有成熟工具的成果。
3
呵呵,我才从这个坑里爬出来,以前jSqlBox是基于Spring-JDBC内核,后来赚它太啰唆,嘛事没干就整了一大堆异常出来,而且捆定在一大堆Spring库上,后来干脆全部重写一遍,转到DbUtils内核上了。现在除了Hibernate本身已经太臃肿,其它所有出名的持久层工具都有二次开发的项目或插件了:EBean、MyBatis、DbUtils、Spring-JDBC,还有一些是自已写内核如jFinal、BeetlSql等。
顺便说一下,个人认为用Java语法来写SQL是一种反模式,更何况你这种写法是基于字符串,不支持重构,建议参考一下BeetlSql中支持重构的SQL写法一节,因为Java的Lambda不支持方法名作为参数,所以有点小痛苦。
最新评论
0

引用来自“开源中国首席最强王者”的评论

比mybaties好用吗?
好用说不上,比mybatis开发效率高,可维护性更好
比mybaties好用吗?
0

引用来自“shifeng1983”的评论

https://www.oschina.net/p/simple-jdbc-templete 欢迎大家指点,要比博主这个封装的好用的多,逻辑清晰,代码更简洁
建议去看看我github上完整的文档再来评论
0

引用来自“yong9981”的评论

数据库持久层开发涉及的方面比较多,通常要考虑这些方面:跨数据库的分页、是否支持DDL、是否支持模板及是否可切换模板、是否自行开发事务或兼容Spring事务、多数据源支持、对象映射、对象关联查询、实体Bean注解、主键生成方案、是否提供ActiveRecord模式、是否提供SqlMapper模式、是否可以在代码里直接调用SQL,是否有可能写出支持重构的SQL功能、是否尺寸小、易学习、依赖库少、是否有1+N这个坑以及解决方案、是否支持多行SQL文本, 是否可以不用XML,是否是个独立的持久层工具......, 等等。
另外文档的完备、源码本身质量、项目的成熟度和普及度也很重要。
目前Java界各种持久层工具层出不穷,正是因为目前各个持久层工具都不能完全达到上述所有要求,所以总是有人想要发明更新的工具,通常有两种模式:在现有工具上作二次开发,或是从头全部自已开发。这两方面的代表举两个例子分别是MyBatis-Plus和BeetlSql。在现有工具上作二次开发,优点是只需要补上缺少的功能即可,缺点是继承了原工具的缺陷,如MyBatis-Plus必须支持繁琐的XML,还有你这个插件只能用于Spring环境中。从头开发的优点是可以获得一个比较优良的架构,缺点是工作量大,不能利用现有成熟工具的成果。
文档里面有详细的说明,并不是只能用在spring环境里面
4
数据库持久层开发涉及的方面比较多,通常要考虑这些方面:跨数据库的分页、是否支持DDL、是否支持模板及是否可切换模板、是否自行开发事务或兼容Spring事务、多数据源支持、对象映射、对象关联查询、实体Bean注解、主键生成方案、是否提供ActiveRecord模式、是否提供SqlMapper模式、是否可以在代码里直接调用SQL,是否有可能写出支持重构的SQL功能、是否尺寸小、易学习、依赖库少、是否有1+N这个坑以及解决方案、是否支持多行SQL文本, 是否可以不用XML,是否是个独立的持久层工具......, 等等。
另外文档的完备、源码本身质量、项目的成熟度和普及度也很重要。
目前Java界各种持久层工具层出不穷,正是因为目前各个持久层工具都不能完全达到上述所有要求,所以总是有人想要发明更新的工具,通常有两种模式:在现有工具上作二次开发,或是从头全部自已开发。这两方面的代表举两个例子分别是MyBatis-Plus和BeetlSql。在现有工具上作二次开发,优点是只需要补上缺少的功能即可,缺点是继承了原工具的缺陷,如MyBatis-Plus必须支持繁琐的XML,还有你这个插件只能用于Spring环境中。从头开发的优点是可以获得一个比较优良的架构,缺点是工作量大,不能利用现有成熟工具的成果。
0
https://www.oschina.net/p/simple-jdbc-templete 欢迎大家指点,要比博主这个封装的好用的多,逻辑清晰,代码更简洁
0

引用来自“chenjazz”的评论

mybatis也是基于字符串的吧,重构这块是个问题。只能依靠数据库设计的稳定性和IDE全局搜索。
重构这个功能对于复杂的SQL来说,是没必要的,很长的SQL一来比较少见,二来写在XML或文本文件中可读性好,便于DBA阅读。
但是重构功能对于简单的SQL还是有用的,不能一棒子打死,尤其当逻辑简单但实体字段很多的场景下。通常意义上的实体-数据库映射本身的目的就是提供重构功能,但限于CURD方法。
实际上对于简单的SQL来说,BeetlSql引入一种Lambda方法来支持重构,jSqlBox则建议利用Inline方法中的字符串常量(或将来考虑引入Lambda方法)来解决。
0
mybatis也是基于字符串的吧,重构这块是个问题。只能依靠数据库设计的稳定性和IDE全局搜索。
3
呵呵,我才从这个坑里爬出来,以前jSqlBox是基于Spring-JDBC内核,后来赚它太啰唆,嘛事没干就整了一大堆异常出来,而且捆定在一大堆Spring库上,后来干脆全部重写一遍,转到DbUtils内核上了。现在除了Hibernate本身已经太臃肿,其它所有出名的持久层工具都有二次开发的项目或插件了:EBean、MyBatis、DbUtils、Spring-JDBC,还有一些是自已写内核如jFinal、BeetlSql等。
顺便说一下,个人认为用Java语法来写SQL是一种反模式,更何况你这种写法是基于字符串,不支持重构,建议参考一下BeetlSql中支持重构的SQL写法一节,因为Java的Lambda不支持方法名作为参数,所以有点小痛苦。
顶部