Spring Boot 自定义应用开发框架九——基本增删改查“低代码”框架初设计2

上一篇简单讲了下基础增、删、改、查基础操作的低代码处理的一种模式，而在实际项目中分页列表是最重要的一块，因为分页列表是每一个模块的切入点，基本所有的功能都是围绕分页列表展开，例如搜索、分组、导出、增、删、改等等。

分页列表功能大家应该都是非常熟悉的，后端传给前端的数据就只有2类，一类是要展示的所有列表信息数据，另一类就是分页的基本属性数据，如总条数，当前页码等。一般我们都会定义一个Page对象专门用于分页数据的处理。

数据查询

分页列表的数据查询一般都分成2种情况，一种是默认情况下最大范围的数据（一般不带搜索条件），另外一种就是用户通过搜索查询后的数据。我们在实现分页列表功能时，之前的常规做法都是在XML文件中根据搜索条件是否存在来拼接SQL语句，这样做有很多弊端，例如
1.功能的搜索非常多，那么XML中的SQL语句判断语句也会非常多，导致后期维护困难；
2.前端页面上搜索与后端的SQL中代码强匹配且单一，例如搜索中有一个字段是日期类型，理论上可以有7种搜索方式，如 大于、小于、等于、大于等于、小于等于、不等于、范围 。虽然可以给这个字段再新增一个不等式来解决这个问题，但如果这个分页列表不止一个日期，甚至还有数字类型字段查询，例如年龄、薪酬，工作年限等，这样做就非常不友好了。
以用户与角色表为例，查询用户列表，SQL如下

从上面的SQL中可以看出，页面上有3个搜索属性，分别为名字、年龄、薪酬，对应的SQL中也要写3个if，如果查询条件越多，那这里的判断也就越多。

页面展示

分页列表页面一般主要分为2个展示区，一个是操作功能区，另一个就是数据展示区域，如下图

上面的红框内就是操作功能区，主要是搜索、批量操作、分组等，下面的红框就是数据展示以及单条数据的操作。这里的最关键的就是功能区的大多数常规操作都是与分页相关联，例如搜索，分组，其实最终到后台都是分页的SQL语句的写法。按照常规的做法就是上面《数据查询》中图片里的做法，根据前端页面上的搜索条件来判断，这样做虽然也能实现分页搜索功能，但是缺点很多：
1.如果搜索条件有变更，前后端都需要更改
2.搜索条件比较单一，例如下拉列表，日期，数值型数据搜索
3.后期维护成本比较高
那我们有没有办法解决上面的问题的，答案肯定是的，通过上面的分析，我们要解决的问题有以下几点
1.搜索属性可以根据需要新增或剔取，而不用修改前端页面以及后端的代码、SQL语句
2.搜索条件表达式可以根据数据属性自动生存，例如字符串搜索是like，下拉列表有 =、in，数值与日期则有范围判断等等
3.新增、编辑页面的通过配置字段生成
只要能解决上面几点，那么大多数功能性页面就可以通过配置生成出来，前后端只需要根据固定流程生成代码即可，后端人员只需要编写分页的主体SQL语句即可,搜索条件与排序的SQL均通过前端提交的参数生成，而且对于后端来说，因为大部分模块流程都是一样的，完全可以根据数据表结构生成所有代码，最终开发人员需要做的只是在XML里编写分页的主体SQL语句。

最终效果

SQL 如下图所示，只要如下编写查询主体即可，相应的where语句与排序不需要填写

后端controller代码

service、dao层代码按照流程正常写就可以了，这里就不贴出来了。
简单说明：Page 就是分页数据结构对应的实体，例如包含
currentPage ：当前页码，totalPage ：总页码, number ：一页条数, results ： 返回的信息结构
NsResponse : 前后端统一的数据通信结构 ，如下

public class NsResponse<T> implements Serializable {
	private static final long serialVersionUID = 11950863444851297L;
	private boolean succeed;
	private String code;
	private String message;
	/**
	 * 返回额外参数
	 */
	private T data;
}

以上就是后端需要编写的全部代码，那么接下来就是怎么实现相应的查询、排序效果呢。
我们都知道，大多数分页列表功能最终体现就是SQL语句的编写，而一个项目中绝大多数模块功能的分页SQL格式基本都是一样的，以笔者的经验来说，一个项目中90%的分页SQL 可以分为4部分

1. 要显示的内容
2. 多表之间的关联
3. 查询条件的处理
4. 排序的处理
   稍微复杂一点的可能还有在查询过程中还要做计算，如查询班级列表时同时显示每个班级的男女生人数，但这种结构也都如上，只是复杂程度更高一点。
   那么我们只要做到在写分页查询SQL时，只编写前2部分，后2部分由后台自动拼装，那么就能实现客户根据自己的配置设置搜索条件以及排序条件。
   对于分页来说，一定会有一个主体显示的内容，其他的内容都是依附于这个主体，我们把这个主体对应的表称为主表，其他信息所在的表为副表，例如显示用户列表时角色表为副表，显示班级列表时学生表为副表。而我们所有的查询与排序的字段肯定在主表和副表中，那么我们只要想办法让前端获取到当前分页列表需要的所有字段（包含主表和副表），并且根据字段的数字属性自动生成查询样式，然后前端与后端设置一个数据结构用于组装查询条件，并将之提交给后端，那么后端就能实现拼装分页SQL。
   
   上面就是简易的分页流程图，从流程图中可以看出，其实关键点就是前端与后端直接查询数据的交互处理这块，只要前后端定义一个基本规则即可。ibatis分页拦截器组装新的SQL都是基于这个规则来编写。

分页查询数据结构

由于本套框架是给公司搭建的，这里也不好将代码讲的太详细，大体讲一下规则的逻辑，大家能明白即可。
我们以前分装分页的类时，一般只考虑了基本常用的几个字段，如下

public class Page<E> implements Serializable {
	/**
	 * 当前页码
	 */
	private int currentPage = 1;
	/**
	 * 一页记录数
	 */
	private int pageSize = 20;
	/**
	 * 总记录数
	 */
	private Integer total;
	/**
	 * 查询的起始索引
	 */
	private int startIndex;
	/**
	 * 额外参数对象
	 */
	private E obj;
	/**
	 * 结果记录集
	 */
	private List<E> results;
}

很明显只有上面的字段肯定是无法满足我们要求的，我们的要求是查询的字段，表达式，排序都由前端配置后传给后端，由后端生成，所以这里需要接收这些内容，我们只要再定义一个接收搜索条件的字段即可，如：
private List pageFieldList;
PageFieldCondition.java 至少要有4个值，对应如下

@Data
@NoArgsConstructor
public class PageFieldCondition implements Serializable {
	/**
	 * 字段名，如果是副表字段需要加上"副表别名.",如果没有表别名，统一当着主表的字段

	 * 如果 role.id
	 */
	private String fieldName;
	/**
	 * 判断条件

	 * 如：eq,lt,le,between
	 */
	private String condition;
	/**
	 * 值
	 */
	private Object value;
	/**
	 * 排序的类型 asc|desc
	 */
	private String order;
}

需要注意的是fieldName 和condition 这两个，fieldName是查询字段名，condition 代表查询表达式，如等于，大于，in等。
定义好这个，前端只要将对应的搜索条件组装好，后端就可以通过拦截器分析数据重新解析成查询条件和搜索条件并拼装成新的SQL即可。
效果如下
后端的SQL

1. XML中的SQL主体

2. 自动拼装的新SQL
   
   判断条件就是按照前端提交的数据生成的，这样做对于后端开发人员的好处就是只要编写分页SQL的主体即可，再也不需要写一堆的 if判断条件，当然这里的案例都是以and为查询条件，基本也能够适用80%以上的环境。