作用就是解耦

目标场景

就是和请假这样

有个人 填了请假单 发起了请假
他填

然后提交了
这个请假的表单是一条记录, 这条记录,填好提交以后, 就不会改了,
请假类型,开始时间,结束时间,事由, 这些都是申请的人申请的时候填的, 提交出去以后就交给下一个人审核了, 这条记录就这样沿着箭头一个个人传阅过去, 到最后那个圆圈代表结束, 这条记录的传阅才算完成

如这个图, 除了申请的人, 后面的直接领导 经理 人事 这些人, 可以决定这条请假记录走向哪里, 比如直接领导和经理可以选择不同意和同意, 但是不会去改他原来申请的表单, 不会他想申请3天 给他改成5天, 他说病假, 把它改成年假
同一个起点, 出去好几个箭头的时候, 就要根据环境中的参数 来判断走哪里,
比如取 按钮这个参数 值是pass箭头就往后走, reject就往回走,
如果天数这个参数 <2 就直接传给人事了, 如果>=2 要传给经理

如果没有activiti

如果步骤比较少, 并且是固定的,比如就传一个领导看下就行了
那么不用Activtit代码写死就好了,
申请人点提交, 记把这条记录数据库里面状态改成比如2
领导点开列表的时候, 给他过滤一下, 状态是2的才给看,
领导同意或者不同意 都把状态改给值
这样通过写死的代码 改动这条记录的状态值 也能实现
缺点是, 耦合度高

其实, 流程和这条数据本身 是可以分离的, 流程并不改这条数据

比如, 今天想领导A来批准, 明天想换成要领导AB都批准了才行
或者要改成 领导B先看过 , 但是不用批, 传给领导C看

如果不用activiti 改起来就麻烦了

activiti的解耦

就是把流程的部分, 和代码分离开
写在怎么一个xml文件里面

图形也有个相应的标准 这个xml文件可以以标准的图形来表示

和上面是同一个文件

可以直接写xml文件
也可以用各自工具, 拖拉图形画图的方式 生成这个流程文件

比如要加一个经理B也看下这个请假申请

拖进去

拉一个用户任务的绿色方形, 加进去就行了

经理B具体代表谁,也不写在代码里面, 在本流程定义文件里面配

经理B可以不是指单个人, 是一组人, 他们几个都能看到申请