流程
没有规矩,不成方圆.
其实流程就相当于我们在编写功能时提前定好的规矩,我们一般编写的功能都是按照甲方爸爸的要求编写的,所以功能执行的过程就应该是按照甲方爸爸定义的流程来编写的.那么我们就能理解流程的概念了.
理解完流程的概念之后,我们就需要了解一下我们一般是怎么执行流程的呢?
一般的流程我们自己设计流程表,然后将我们的流程表与我们的业务数据进行绑定,这样我们的流程就能一步一步的进行下去.我们通过一个请假的流程 来描述一下一般我们是怎么实现这个功能的:
可能一开始看上面的流程会觉得,这样挺好的,一目了然,清清爽爽.说实话,我第一次也是这样觉得呢,这不挺好的嘛.但是告诉你都是假象.
在上面的设计过程中我们不仅要管理我们的业务数据,同时还要管理我们的任务数据,并且各个任务数据可能还存在着一定的关联关系,这种关联关系我们肯定也要保留,否则我们怎么能确定,主管到底审核的是谁的请假申请!!!所以说就会明显增加我们对于数据的管理压力.
这样的设计方式也不能说他是错的,但是随之时代的发展,势必就会产生下面的局面:部门越来越精细(就是他娘很多部门的意思),流程越来越复杂,处理的时间越来越长…
在这这样的情况下,如果还是我们自己设计表,然后与我们的业务数据进行绑定的话,那么显然不仅开发的难度会上升很多,同时在后期的维护难度上也会增加很多.所以还是得通过流程框架来帮助我们更加高效的开发流程.
改动需求–>逼死程序员
说完流程的大体概念之后,我们来稍微了解一下为什么需要流程框架来帮助我们简化流程的开发.原因就那么几点,一个就是开发的难度越来越大,流程越来越复杂,另外一个就是需求整天变个不停.你想想你不用流程框架之前好不容易把一个流程写完了,还没两天客户说流程改了,你什么心态??
顺便和大家讲一下需求改了之后我们具体哪些地方使我们最头疼的.
相信大家在开发的过程中最烦的就是需求一直在发生变化.因为需求一旦发生改变,那么就会引起下面一连串的反应.正如下图所示:
就是因为会有上面一系列的连锁反应,所以后端开发人员一般都是在需求尽可能详细的说明书出来之后才开始开发的.
因为一旦需求发生改变.那么下面的几项基本上也是肯定需要发生改变的.
数据库重构
这个大家应该都能明白.就算不明白,举下面一个栗子.大家就懂了.
假设我们之前设计的一张关于用户User的表是下面这样的:
但是呢客户现在提新的需求了,我们需要把用户的详细信息包括:电话号码,家庭住址,学历等等信息全部存储下来,那么显然我们数据库中关于User这张表就需要重构.而且重构会出现下面两种情况:
1.直接在原来的表上面添加字段.
2.新建一张表,在该表上添加字段,之后再将两张表关联起来.
可能这时候会有人说了,第一种方案不是挺好的嘛,第二种方案不是鲨雕吗!!还专门再建一张表关联起来,真实有够好笑的呢!!
其实并不是我鲨雕,这个其实是要看情况的,很明显我们上面的样例User表,可以直接在表上面添加字段就行了,但是如果是下面这张User表呢?
假设我们的表里面已经有了30个甚至更多的字段之后,那么我们还能继续添加字段吗?显然这样做就很蠢,相当蠢,非常蠢,确定一定以及肯定的蠢了.
因为 一张表中的字段过多 了之后就会严重影响我们关于数据库各项操作的性能.所以我们只能选择分表然后关联的操作.这样才能相对来说继续维持我们数据库相关操作的性能.
流程需要重新编写
这个其实大家也能理解.我们还是举一个栗子来帮助大家理解:
假设我们之前开发了一个功能是关于请假的.
假设我们之前的请假流程是这样的:
但是需求改成这样了:
那么显然相应的我们关于该请假流程的整个编写过程就要发生改变.所以我们后端开发最最最最最讨厌需求有重新发生了改变,这样就使得我们整个的开发过程会异常的漫,并且有时候甚至会出现 重构的过程比推倒重新做花的时间还要长.所以我们常常能够看到什么程序员与产品经理打架的新闻,这个也是正常的.
模块之间产生新的耦合关系
如果只是上面的还好,就怕客户提了一个之前没有提到过的模块,如果这个模块只是关联到我们最开始的模块或者是最后的模块,其实都是还好的,就怕他提的功能模块是卡在两个模块中间执行的,这就要命了.不仅要和前一个模块进行绑定,同时又要与后一个模块进行绑定.两头为难.
这就好比某奇艺的骚操作,看网剧的时候好不容易等你熬过了开头的广告,之后好不容易看了半集电视剧了,他又给你整了个插播广告,看完插播广告你才能看下面半集电视剧,你说你气不气.
Activiti7相当方便快捷
讲了那么多关于流程以及流程开发复杂的 东西,下面我们来简单将一下Activiti7是如何帮我们实现的吧!
这里先简单的讲解一下,详细的教程会在下一篇博客里面完整的分享出来.
首先第一点,关于流程的表都不需要我们在单独设计创建,Activiti7会帮我们自动创建并且管理 ,想想看,这是一件多么美好的事,基本上流程的所有问题全部都交给Activiti7就能完成.
第二点Activiti7大大的简化了我们之前重复性的管理任务信息以及关联的操作.
我们首先需要理解Activiti7的流程运转过程.我们可以通过下面的图来进行理解:
在Activiti7中是采用一开始就把操作的整个流程部署好,这样每个用户的操作就会按照这个流程走就行了.
那这样我们按照这个顺序来走一遍
我们先来绘制一张BPMN文件.
可以看到我们在BPMN文件中就已经定义好了整个流程的运转过程,并且将流程中的操作细分成了相应的任务节点—(发起请假,审批请假),用户每操作完一个动作,相应的任务节点就完成,交付给下一个任务节点,当所有的任务节点都完成了以后这个流程就结束了.
这样就使得我们不用在考虑如何存储任务节点以及他们的关联信息了,这些操作全部都交给 Activiti7来操作就行了.
之后我们就只需要将该流程定义部署起来:
@Autowired private RepositoryService repositoryService; //根据bpmn部署流程 @Test public void initDeploymentBPMN(){ String filename="BPMN/Part4_Task.bpmn";//BPMN文件所在的位置 Deployment deployment=repositoryService.createDeployment() .addClasspathResource(filename) .name("流程定义部署测试") .deploy(); System.out.println(deployment.getName()+",部署成功"); }
这样我们的流程定义就部署成功了.
之后我们就需要去初始化该流程定义的一个流程实例:
@Autowired private RuntimeService runtimeService; //初始化流程实例 @Test public void initProcessInstance(){ ProcessInstance processInstance=runtimeService.startProcessInstanceByKey("myProcess_Task");//BPMN文件的Id名 System.out.println("ID:"+processInstance.getId()); System.out.println("ProcessInstanceId:"+processInstance.getProcessInstanceId()); System.out.println("ProcessDefinitionId:"+processInstance.getProcessDefinitionId()); }
这样我们的流程实例就已经创建完毕.之后我们就可以一步一步的执行我们的流程实例中的任务节点了.
@Autowired private TaskService taskService; //执行任务 @Test public void completeTask(){ taskService.complete("2d22f941-3f67-11eb-b3b6-3c58c24c1a1b");//任务节点的ID号 System.out.println("该任务节点已经处理完毕"); }
这样我们就可以完成我们的任务节点,等到所有的任务节点都完成之后我们的流程就完成了.
是不是非常的方便快捷.
并且就算甲方爸爸修改了需求,我们只需要重新绘制我们的BPMN文件,之后在重新部署,再将我们相应的完成任务节点的操作与我们的业务数据对应即可.相当快速.不用再像之前一样了.
到这里一个简单的请假流程就编写号了,是不是相当的方便快捷!!!
