本篇博客的主要内容是：【请假审批内嵌页面】，【审批弹出框】的点击“确认提交”后，后台的逻辑：主要是Dao层和Service层这些后台逻辑；

 说明：

（1）目前来看，为了实现某个功能，【一个比较好的编程逻辑和实现流程】比【实际敲代码去实现】重要的多得多！！！） 

（2.1）底层的SQL语句，updata和insert语句的参数，一般是一个实体类对象，注意一下这个习惯（或者说是普遍采用的策略）；

（2.2）而且，一般为了更新某些数据，一般的策略先查询出要更改数据，用一个实体类对象去承载；然后，修改这个实体类对象，然后再调用update方法（updata的参数就是这个修改后的实体类对象），已达到更新这些数据的目的；

（2.3）2.2中的例子可以看出，我们尽量在Mapper xml中编写那些具有通用性的SQL，或者说是可以完成某个“普遍性”功能的SQL语句；这样一来，当我们需要完成某个具体的业务逻辑的时候，就可以调用这些【具有“通用性、普遍性”功能的SQL语句】，来完成我们具体的某个业务逻辑！这一条思想非常重要！！！

目录

一：【审批】流程和逻辑分析

（1）如果请假时间 >= 72小时：需要【部门经理审批】和【总经理审批】

（2）如果请假时间 < 72小时：需要【部门经理审批】和【总经理审批】

二：通过【一：【审批】流程和逻辑分析】中的分析，构思具体编码的的实现分支和结构

三：具体的实现 

 1.第一个步骤：无论审批结果是同意还是驳回，当前任务状态变更为complete；

（1.1）首先，在process_flow.xml中编写SQL语句

（1.2）然后，在ProcessFlowDao中，编写上述在process_flow.xml中声明的两个SQL语句的方法声明

（1.3）然后，在LeaveFormService中，编写实现【把当前任务状态变更为complete；】的业务逻辑

 2.第二个步骤：如果当前任务是最后一个节点，代表流程结束，更新leave_form表中的请假单状态为对应的approved或者refused

（1）首先，在leave_form.xml中增加两个SQL语句；

（2）然后，就在LeaveFormDao中编写方法的定义

（3）然后，就在LeaveFormService中，调用Dao层方法，实现本步骤的逻辑

3.第三个步骤：如果当前任务不是最后一个节点，如果审批通过，那么下一个节点的状态从ready改为process

4.第四个步骤：如果当前任务不是最后一个节点，如果审批驳回，则后续所有任务的状态变为cancel，同时更新leave_form表中的请假单状态为refused

5.最后的一个设置，因为整个操作不需要返回值，所以return null；

四：测试

（1）测试数据

（2）编写测试用例

（3）实际运行测试用例 

---

一：【审批】流程和逻辑分析

（1）如果请假时间 >= 72小时：需要【部门经理审批】和【总经理审批】

如上，目前的审批环节是【部门经理审批】。

（情况一：中间节点审批通过了：）

● 如果部门经理审批通过：

然后，【总经理】审批了：总经理审批：总经理可能审批通过，也可能审批不通过

（情况二：中间节点审批不通过： ）

● 如果部门经理审批不通过：那么这个请假直接就无需总经理审批了，直接不同意了。

（2）如果请假时间 < 72小时：需要【部门经理审批】和【总经理审批】

（情况三：当前节点是最后一个节点：）

 即，【审批的流程和逻辑】可以抽取成三个不同的情况：【情况一：当前审批是中间节点，而且审批通过了】；【情况二：当前审批是中间节点，但是审批没通过】；【情况三：当前审批是最后一个的节点】；

---

二：通过【一：【审批】流程和逻辑分析】中的分析，构思具体编码的的实现分支和结构

通过【一：【审批】流程和逻辑分析】中的分析，在实际编码的时候，其实现逻辑可以梳理为：

1.无论审批结果是同意还是驳回，当前任务状态变更为complete；（即，只要当前环节审批了，无论同意还是驳回，当前审批环节审批后，当前环节的状态都需要改为complete）

2.如果当前任务是最后一个节点，代表流程结束，更新leave_form表中的请假单状态为对应的approved或者refused

3.如果当前任务不是最后一个节点，如果审批通过，那么下一个节点的状态从ready改为process

4.如果当前任务不是最后一个节点，如果审批驳回，则后续所有任务的状态变为cancel，同时更新leave_form表中的请假单状态为refused

（PS：这个【为了实现某个功能，构建更加良好的代码结构和逻辑】的能力，需要慢慢提升啦；确实，目前来看，【为了实现某个功能，一个比较好的编程逻辑和实现流程】比【实际敲代码去实现】重要的多得多！！！） 

---

三：具体的实现 

 1.第一个步骤：无论审批结果是同意还是驳回，当前任务状态变更为complete；

（1.1）首先，在process_flow.xml中编写SQL语句

经过思考后，可以发现，为了实现本步骤的逻辑，需要两个底层的SQL操作：一个是查询当前表单的所有审批环节；二是，更改某一审批环节；

（PS：上面的selectByFormId马虎写错了，多了一个c....所以，及时的单元测试非常重要！！） 

process_flow.xml：上述新增内容的代码

    <select id="selectByFormId" parameterType="Long" resultType="com.imooc.oa.entity.ProcessFlow">
        select * from adm_process_flow where form_id = #{value} order by order_no
    </select>

    <update id="update" parameterType="com.imooc.oa.entity.ProcessFlow">
      UPDATE adm_process_flow SET form_id = #{formId}, operator_id = #{operatorId}, action = #{action}, result = #{result}, reason = #{reason}, create_time = #{createTime}, audit_time = #{auditTime}, order_no = #{orderNo}, state = #{state}, is_last = #{isLast}
      WHERE process_id = #{processId}
    </update>

（1.2）然后，在ProcessFlowDao中，编写上述在process_flow.xml中声明的两个SQL语句的方法声明

（1.3）然后，在LeaveFormService中，编写实现【把当前任务状态变更为complete；】的业务逻辑

实现【第一个步骤：无论审批结果是同意还是驳回，当前任务状态变更为complete；】的代码：

    /**
     *
     * @param formId:该条请假信息的formId（可以从前台传过来的）
     * @param operatorId：经办人编号（从当前的session会话对象中获得的）
     * @param result：审批结果（可以从前台传过来的）
     * @param reason：审批意见（可以从前台传过来的）
     */
    public void audit(Long formId,Long operatorId,String result,String reason){
        MybatisUtils.executeUpdate(sqlSession -> {
            //1.无论审批结果是同意还是驳回，当前任务状态变更为complete
            //(1.1)首先获取，当前表单的所有流程数据；
            ProcessFlowDao processFlowDao = sqlSession.getMapper(ProcessFlowDao.class);
            List<ProcessFlow> processFlowList = processFlowDao.selectByFormId(formId);
            if (processFlowList.size() == 0) {  //if判断，是作了一个容错处理，如果查询的流程数据为0的话，需要抛一个异常；
                throw new BussinessException("PF001", "无效的审批流程");// 这个错误编码是自定义的；
            }
            //(1.2)获取当前审批环节的数据
            //获取当前的审批流程：一个审批流程要想判定为是当前审批流程需要满足以下两个条件：一是当前环节的状态state应该为process；二是当前环节的经办人operator_id应该是当前的登录用户。
            // 通过Lambda表达式的Stream流来做数据筛选的
            List<ProcessFlow> currentProcessFlowList = processFlowList.stream().filter(p -> p.getOperatorId() == operatorId && p.getState().equals("process")).collect(Collectors.toList());
            ProcessFlow processFlow = null;
            if (currentProcessFlowList.size() == 0) {  //if判断，是作了一个容错处理，如果没有在process_flow表中找到当前审批流程，需要抛一个异常；
                throw new BussinessException("PF002", "未找到待处理任务");// 这个错误编码是自定义的；
            } else { //如果找到了当前审批流程数据，就把这个审批流程数据提取出来
                processFlow = currentProcessFlowList.get(0);
                processFlow.setState("complete");
                processFlow.setResult(result);
                processFlow.setReason(reason);
                processFlow.setAuditTime(new Date());
                processFlowDao.update(processFlow);
            }

            //2.如果当前任务是最后一个节点，代表流程结束，更新leave_form表中的请假单状态为对应的approved或者refused
            //3.如果当前任务不是最后一个节点，如果审批通过，那么下一个节点的状态从ready改为process
            //4.如果当前任务不是最后一个节点，如果审批驳回，则后续所有任务的状态变为cancel，同时更新leave_form表中的请假单状态为refused
        })
    }

说明：

（1）因为所有的审批操作，要么全部OK，要么全部不做，所以把上面的代码，都写在了一个【MybatisUtils.executeUpdate()】中：

（2） 首先，获取【当前表单的所有流程数据】；其中加了一个判断的容错处理，如果一切正常的话，应该会获取得到的，但是万一获取不到，就抛出一个自定义的BussinessException异常；

（3） 然后，从【当前表单的所有流程数据】中，筛选出【当前审批环节的数据】；其中加了一个判断的容错处理，如果一切正常的话，应该会获取得到的，但是万一获取不到，就抛出一个自定义的BussinessException异常；（因为，在前面显示【待审批请假数据】的时候，就是按照这个规则筛选的。但是，如果万一由于某些原因找不到的话，就报异常）

这儿使用了Lambda表达式的stream流来做的，如果忘记了，可以参考Lambda表达式七：Stream流一：Stream介绍及附近相关文章。

（4）更新当前审批环节的数据

---

 2.第二个步骤：如果当前任务是最后一个节点，代表流程结束，更新leave_form表中的请假单状态为对应的approved或者refused

（1）首先，在leave_form.xml中增加两个SQL语句；

因为为了实现第二步的逻辑，底层需要两个SQL支撑：一是根据form_id查询form表单数据；二是更新某条form表单数据

（PS：上面update标签中的参数写错了，写成了LeaveForm，实际上应该是com.imooc.oa.entity.LeaveForm，而这个错误在后面运行发布的时候也导致了NoClassDefFoundError错误，以至于系统无法登录。所以，及时的单元测试非常重要！！！） 

leave_form.xml中增加两个SQL语句的代码：

    <select id="selectById" parameterType="Long" resultType="com.imooc.oa.entity.LeaveForm">
        select * from adm_leave_form where form_id = #{value}
    </select>

    <update id="update" parameterType="com.imooc.oa.entity.LeaveForm">
        UPDATE adm_leave_form SET employee_id = #{employeeId} , form_type = #{formType}, start_time = #{startTime}, end_time = #{endTime}, reason = #{reason}, state = #{state} ,create_time = #{createTime} WHERE form_id = #{formId}
    </update>

（2）然后，就在LeaveFormDao中编写方法的定义

（3）然后，就在LeaveFormService中，调用Dao层方法，实现本步骤的逻辑

---

3.第三个步骤：如果当前任务不是最后一个节点，如果审批通过，那么下一个节点的状态从ready改为process

从这儿就可以看到，因为前面我们编写底层SQL语句的时候，都是编写的【具有“通用性、普遍性”功能的SQL语句】，所以，在本步骤我们直接调用那些【具有“通用性、普遍性”功能的SQL语句】来完成【本步骤这个具体的业务逻辑了】

---

4.第四个步骤：如果当前任务不是最后一个节点，如果审批驳回，则后续所有任务的状态变为cancel，同时更新leave_form表中的请假单状态为refused

从这儿就可以看到，因为前面我们编写底层SQL语句的时候，都是编写的【具有“通用性、普遍性”功能的SQL语句】，所以，在本步骤我们直接调用那些【具有“通用性、普遍性”功能的SQL语句】来完成【本步骤这个具体的业务逻辑了】 

---

5.最后的一个设置，因为整个操作不需要返回值，所以return null；

---

四：测试

（PS：感觉在实际开发中，最好还是每写完一个Service模块或者是每写完一个Dao模块就测试一下，不要等到一个功能全部编写完了之后再测试）

（1）测试数据

可以看到，共有三条测试数据，其form_id依次是31，32，33；

 （2）编写测试用例

 针对本次测试内容，编写以下三个测试方法：

package com.imooc.oa.service;

import com.imooc.oa.entity.LeaveForm;
import org.junit.Test;

import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Date;

import static org.junit.Assert.*;

public class LeaveFormServiceTest {
    LeaveFormService leaveFormService = new LeaveFormService();

    /**
     * 请假3天以上,部门经理审批通过
     */
    @Test
    public void audit1(){
        leaveFormService.audit(31l,2l,"approved","祝早日康复");
    }

    /**
     * 请假3天以上,部门经理审批驳回
     */
    @Test
    public void audit2(){
        leaveFormService.audit(32l,2l,"refused","工期紧张,请勿拖延");
    }

    /**
     * 部门经理请假,总经理审批通过
     */
    @Test
    public void audit3(){
        leaveFormService.audit(33l,1l,"approved","同意");
    }

}

（3）实际运行测试用例 

 运行audit1()：

运行audit2()：

运行audit3()：

 

---

至此，说明业务逻辑部分编写就OK了，接下来就是编写Controller和前台界面了。 

标签：逻辑,Service,form,process,当前任务,SQL,审批,节点
来源： https://blog.csdn.net/csucsgoat/article/details/118050392