【思想篇】工作流技术JBPM4.4开发入门（五）

继上篇博客

 

上篇博客我们将现有的实现介绍了一番，不知道大家有没有发现问题，也有可能因为我并没有贴上相应的代码，大家很难理解，下面我来说明一下：

 

首先说，之前的那种方式是实现了工作流类似的功能，但是它的实现方式，却没有做到灵活，而是加强了和业务的耦合，而且并没有实现工作流管理业务。

 

我们一再强调，工作流管理业务，每个工作流结点并不知道业务需要做什么，每个结点也不知道要实现什么功能，这一切的操作都要看业务给了我们什么，当业务结点扔到工作流程中，那么业务就被工作流管理起来了，而业务要实现的功能由业务提供。

其实这也就是说我们常说的委托实现，我们不再靠强耦合去调用相应的方法，而是在于业务主动向外提供给我们什么服务。

 

这种方式的实现更强调实现流程的复用，以及工作流管理业务。即我画好一个流程图，那么他的结点个数已经确定，而此时业务和这个结点绑定什么业务，那么这个结点就实现什么功能，这时我们不但结点复用，而且流程同样可以复用

 

对比前后两种方式的区别：

 

之前方式：

优点：

 

1，对于已经使用工作流的业务，应对业务变更不需要编写任何代码

 

缺点：

 

1，业务和工作流的方法完全耦合在一起，只是将工作流的方法单独抽象来了一个类而已。当然实现功能是没有问题，而且所有的业务只要是继承我们抽象出来的工作流方法就可以很好的共用这套方法，但是这就需要我们业务要懂得我们抽象出来的方法的含义

2，不能实现整个流程的复用。因为和业务的耦合

3，之前的方式更强掉的是业务的变更。（对于已经使用工作流的业务的变更，如果是之前并没有使用工作流，后来想要应用的话，维护很不便。因为和业务的耦合）

4，并没有体现出工作流管理业务

5，不能应对扩展

 

思考：

改进方式：

 

抽象出来单独的结点池，所有的业务都使用使用这些结点池中的结点，对于具体业务要什么通过委托的方式实现！

 

//结点池1

publicvoid test1(){

//启动流程

//调用委托

//调用完成当前结点

}

 

//结点池2

publicvoidtest2(){                

//调用委托）

//调用完成当前结点

}

 

优点：

 

1，实现流程的复用

2，真正做到和具体业务解耦

3，扩展方便

4，由工作流管理业务（开发结点池，只要是使用工作流，那么它的结点池就已经设置好了执行过程）

5，当然也能应对业务的变更

 

 

总的来说，虽然第一种方式实现了业务的变更，但是这并不是工作流出现的核心目的，这仅仅是应用工作流的第一步，随着我们对工作流的理解我们应该将它应用的更加淋漓尽致。当然也很有可能，到现在我们的理解还不是很透彻，还不是很成熟，这都是学习的一个过程，在实践中再不断完善！