spring mybatis 真正的快速开发-介绍开始篇

前言：

      目前市面上基于spring mybatis的快速开发框架其实很多，大部分都带有代码生成功能；2年前我们刚做项目的时候，其实也自己研发了很多能够生成代码的可视化工具，也不乏有些工具称能够解决80%的开发，但是到实际业务当中，由于业务的多变化，除非是特别简单的某某代码管理之类的，确实很快，但是大部分还需要程序员来写大量的java、jsp代码来完成。算了，本来想多写点，但是觉得废话太多哈。

      简单点说，就是在工业4.0的时代，我们技术含量号称很高的程序员行业，还用原始的代码堆砌来一行行写，也许是我见识比较少，但是大公司我也待过，基本就是原始状态的累代码。

      这也是为什么互联网热潮一退去，大量公司倒闭的主要原因，因为程序员的成本很高，但是产出却用原始的方式在干活，除非高利润的运营型产品或者政府等利润率较高的行业，否则现在的软件项目我觉得很难赚钱，基本就是给程序员发工资，不亏就不错了。

      我们在做项目的过程总，经过几个步骤的痛点，一步步优化开发的技术框架，最终实现，现有的同样开发水平程序员，抛出业务理解时间（其实业务理解错了，改起来也要快），能够提升至少1倍以上的产出。下面开始说下演变过程：

 

演变1的诱因：

1、原始的mybatis的配置文件，都是必须要配置到xml文件中，稍微有表关联或一些个性化一点点的就需要改xml文件，写xml配置方法有几个问题：

• 每次写完都要重启服务，有些稍微重一点的重启要很久
• 改mapper-xml特别容易出错，不是写错字母了，就是少写条件，不停的改、重启
• 写mapper-xml中的函数需要在dao、service中配置对应的方法，整个过程非常繁琐
• 开始的目的是公用mapper-xml中的函数给多个业务使用，但是却发现，每个业务要用的字段、关联表、查询条件都不同，导致一个函数越来越复杂
• 最可怕的是，公用的函数一旦其中一个业务有bug，改动后，很可能导致另一个业务出现问题，这样会有两种后果，第一，项目验收时出现有50bug，但是全部改完这50bug以后，发现又出现了25个新bug，就是因为改了公用函数，第二，基于第一个原因，导致后续维护时，没有人敢去改xml中的条件内容，即使就差了一点点条件不同，就去重新写一个方法，导致xml越来越庞大且不可维护。

2、关于实体bean或者说entity，实体bean的初衷是只对应数据库的表，但是由于实际业务在页面显示、传参肯定不会是单表，这样就带来几个问题：

举例：对于实体entityA，里面有三个字段，但是实际要显示到页面业务的时候，需要用到entityB、entityC各2个字段；这时就需要在实体entityA中增加这几个字段，同样实体b、c的某些业务又需要其他的字段，字段可能是数据字段，也可能是一个list、map等类型；这样就需要在一个实体中不停的增加字段，假如增加了8个字段，但是某个业务只用到一个额外字段而已。

• 实体中字段不断在增加，导致维护、修改起来很混乱
• 增加字段同样意味着要重启服务
• 实体中增加的某些字段，通常会作为关联表的查询字段，这时还需要去修改mapper中的查询条件
• 同一个实体，在同一个业务中作为查询条件、显示字段所需要的额外字段不同

3、当写接口时（app的json接口），明明与后台管理是同一个方法，但是由于接口必须返回map，且接口要求用到哪个字段返回哪个字段，不能一个实体中的全部字段都返回，必须要重新定一个新的xml方法，重新定义select的字段，非常繁琐。

4、当用到groupby、获取count等聚合函数时均要进行手写函数，对开发人员要求较高。

演变1

（声明一下：所有我们的项目的实体、mapper文件都是使用代码生成器 与数据表一一对应，项目开发完成，实体没有增加任何一个非数据库字段、mapper没有增加任何一个额外的函数，都是标准的增删改查函数。）

基于上述的问题：我们对mybatis与spring底层部分进行改造，先对一个改造过程进行描述：

• 下面的consultOrderDetail是一个主表，我要将其跟AppUser进行关联，并获取AppUser的realName字段，初始的写法如下：

ConsultOrderDetail consultOrderDetail=new ConsultOrderDetail();

consultOrderDetail.setStatus("1");//(0:待支付 1:待咨询  2:已完成  3:已失效 4:已退约)

JoinTableBean joinTableBean = new JoinTableBean();//创建一个关联表信息

joinTableBean.setTableName(AppUser._TB_TABLE_NAME_);//设置关联的表

joinTableBean.putOnCond(ConsultOrderDetail._custId,AppUser._id);//设置关联条件

joinTableBean.putSelect(AppUser._realName,"appUserRealName");//设置查询条件，并改变别名为appUserRealName

consultOrderDetail.putJoinTable(joinTableBean);//将关联表joinTableBean放到主表中consultOrderDetail.appendWhereCondSql("date_format(date_sub(a.begin_time,interval '24 ' hour),'%Y-%m-%d %H')=date_format(now(),'%Y-%m-%d %H')");//如果有一些额外的复杂查询条件，可以用这种方式拼接上

List<ConsultOrderDetail> findList = this.findList(consultOrderDetail);//最终进行数据查询，这是的findList中的ConsultOrderDetail的每条记录都会增加一个具有set、get方法的属性appUserRealName。直接传到前端jsp页面即可显示。

 

演变2：动态属性

我们知道，在一个业务中，比如一个简单的管理功能，其查询字段、列表字段、编辑页面字段所需的字段均不可能来自于一张表，基本都是多个表，如何做到不需要对实体创建字段而实现业务需求呢？

 我们 有一张表guageInfo，我可以手工为通过手工

gaugeInfo=gaugeInfo.initDynaMap("gaugeKind");

该表创建一个字段叫做gaugeKind的动态属性;动态属性如下：

gaugeKind的属性即为虚拟属性，当然其也具有了set、get方法，可以在jsp、mapper中直接使用gaugeKind这字段；

而gaugeInfo=gaugeInfo.initDynaMap(request);这句话表示，从request中获得所有查询字段并自动添加到gaugeInfo中

查询页面条件如下：

这里有几个查询条件是不属于gaugeInfo的。

同理，查询的结果集，也会根据您关联表所设置的select字段而自动包含到主实体中，以便直接到页面显示。

最终形成的sql如下：（这完全是基于上述的函数自动拼接而成的）

拼接参数后sql____________：[com.tengjie.base.modules.gaugeKind.dao.GaugeKindMainDao.findList]:
SELECT a.id AS "id", a.guage_kind_name AS "guageKindName", a.create_date AS "createDate", a.create_by AS "createBy.id", a.update_date AS "updateDate"
    , a.update_by AS "updateBy.id", a.remarks AS "remarks", a.del_flag AS "delFlag", a.org_code AS "orgCode"
FROM tb_gauge_kind a
    INNER JOIN tb_gauge_gauge_kind tbgaugegaugekind17 ON a.id = tbgaugegaugekind17.guage_kind_id
        AND tbgaugegaugekind17.del_flag != '1'
WHERE a.del_flag = '0'
    AND a.org_code = 'c6d9975c3e984f3bbdb15877e66d58bc'
    AND tbgaugegaugekind17.guage_id = 'e42d3bd166b84c76bf2fd9358c5251c5'
ORDER BY a.update_date DESC

今天先写到这里，只是一个粗略的介绍，后续会给出一个针对流行开源系统若依系统的改造

更详细的介绍及如何整合到您现有项目中，请参考https://blog.youkuaiyun.com/kevin_liang_feng/article/details/103337851

项目地址：https://github.com/kevinliang-123/mybatis-topspeed

下一篇