针对一套增删改查涉及到流程的解决方案（干货）

1.第一步流程节点要确保是活的，可以在数据库里面的配置字典表里面去写记录，到时候查这张表的对应的是哪个节点即可，如果没有配置字典表的话，也可以去建一个流程节点表

这样的好处是方便以后的扩展性，可以随时增加新的流程节点，以及流程。可以采用-去拼接

例：1-2-3-4-5代表这个流程完整走完需要经过这五个节点，1，2，3，4，5可以在库里配出说明是什么节点，如果需要增加节点，可以加个节点6，然后配上一个新的流程1-2-3-4-5-6.

2.对于这种流程的通常都会有一个统一的审核页面入口，里面会展示不同流程的信息，然后点击不同的流程时会去不同的页面，这里就需要我们在审核列表里面增加一个页面标识，告诉前端应该去哪个页面，

然后那个页面的数据是通过什么样的接口去查，即这个标识告诉前端去走哪个页面和掉哪个接口

3.审核列表也是需要进行控制的，在不同节点会去展示不同的审核流程，即到该节点的流程，这个就需要用到我们在审核记录表里面里面的下一个节点的字段，这个下一个节点就代表这个流程走到哪个节点，可以用这个条件去查即可，

那么问题来了，这个下一个节点的条件怎么加，这个时候就需要一个叫岗位的东西了，因为审核列表肯定是和岗位关联的，不同的岗位展示不同的审核信息，所以我们可以根据岗位去判断能查出哪个，比如A岗位能查1节点，我们可以根据他的

A岗位去拼上这个条件，sql用下一个节点in就行了，我们可以写一个map，里面key用岗位，值就是节点，这样就很方便去查了。

4.后续扩展上，岗位可能会变成一人多岗的角色，这个时候我们可以用2进制的方式去做处理，比如00，然后第一个0代表A岗位，第二个0代表B岗位，那么11就代表即是A岗位又是B岗位，然后存库的会可以存11也可以存3，这个看你们自己怎么定好了，

然后你的map集合就需要新增一个keyvalue了，个人觉得二进制的方便一点

5.流程上基本上查询的审核列表查出来控制了，跳转的页面也控制了，这时候就到了中间节点了，中间节点基本上下面的操作都是一个的，同意，拒绝，或者退回啥的，我们可以定义一个操作类型，告诉我们是什么操作，我们需要判断的时候要注意是不是最后

一个节点，最后一个节点的话就代表要入库了，中间的节点的话，只需要审核表里面变更下一个节点这个字段即可，至于怎么变更，我们可以查到这个审核表里面的一个审核流程的字段，这个字段告诉我们是什么样的流程，然后我们用我们当前的节点去看

在这个流程中的是哪个索引，然后根据索引+2就是下一个节点的位置的，比如流程1-2-3-4，现在是2节点，我们对应的索引是3，我们只需要取索引下标是5的值，也就是3即可，然后更新审核记录表就行了

6.如果是最后一个节点的话，也就是要入库了，这个时候我们需要的操作就是调用不同的实现类即可，我们可以定义一个公用的接口

public interface BaseSubService<T extends BaseSubInfo>{
        //同意增加
        public void doAddApprove(String pkid) throws Exception;
        //同意更新
	public void doUpdateApprove(String pkid) throws Exception;
        //同意删除
	public void doDeleteApprove(String pkid) throws Exception;

}

　　然后用不同的实现类去实现即可，这个xxx要继承BaseSubInfo这个类的

public class XXXServiceImpl implements BaseSubService<XXX> {
    @Override
    public void doAddApprove(String pkid) throws Exception {
           //实现审核同意增加类型的业务处理
         }

       @Override
    public void doUpdateApprove(String pkid) throws Exception {
       //实现审核同意增加类型的业务处理
         }

       @Override
    public void doDeleteApprove(String pkid) throws Exception {
         //实现审核同意增加类型的业务处理
         }
}

这样我们就可以根据不同的业务去做对应的业务处理了，还有就是入口那里要确定好，这个非常重要,入口的话，我们可以在审核表里面有个操作类型的字段，用来我们最后通过什么样的接口方法去处理，还有就是表名，这个一定要按照规则来，否则找不到

对应的实现类

     //写一段代码查审核表的相关信息
     //定义一个字段获取表名
     //最关键的一步，创建出这个表对应的bean对象
     BaseSubService<BaseSubInfo> info = (BaseSubService<BaseSubInfo>) SpringContextUtil.getBean(表名 + "ServiceImpl");
        int operateType = tbRmmsAuditRecord.getOperateType();
        if (0 == operateType) {
            //新增
            info.doAddApprove(pkid);
        } else if (1 == operateType) {
            //修改
            info.doUpdateApprove(pkid);
        } else if (2 == operateType) {
            //删除
            info.doDeleteApprove(pkid);
        }

这样我们就可以做到统一的入库，统一的最后解决方法，根据不同的业务做不同的处理操作

7.核心表及其字段

’   审核表：有个流程编号pkid,操作类型字段，用来区分最后走接口里面的哪个方法，审核流程步骤字段，用于记录这个流程的所有节点，方便我们流程中的退回同意等操作完跳的对应节点

   下一个节点字段，用来审核列表查询用的，审核状态字段，用来进行校验用的，比如存在审核流程，无法再次发起，然后就是主表字段和附表字段，用来生成对应的service的bean对象的，页面标识字段，用来区分 跳转页面和调用不同接口用的，还有就是时间

    一般用来倒序查询使用的，至于其他字段可以根据自己业务需要增加

   业务附表：一般用来存更改的信息的，用来审核流程展示，和最后替换掉主表的信息使用的，里面核心字段审核流程编号关联审核表的pkid用的，主表的主键，用来关联我们需改变更的是主表的哪条记录使用的，其他字段基本上和主表保持一致，有需要的话

   可以根据业务新增

  主表，这个基本上就是业务需求定字段了，没什么好说的

  最后像什么更新删除等其他操作，基本上先查一下主表数据，然后替换掉对应的字段的值，然后去插入到附表

  如果有什么缺漏考虑不全的地方，欢迎评论补充