一种事件主导流程的设计模式的思考

三个角色

一是事件触发者

二是事件广播者

三是事件处理者

 

事件触发者 触发事件 广播者接收事件 通知所有的事件处理者 事件处理者挑选自己需要处理的事件处理

 

这样做的好处是可以把相同的业物逻辑放在一起来处理

 

比如我们的业务逻辑需要一些相同的工作,比如发短信,减库存,支付扣款等

 

你看,我们新建一张订单 我们一般会写个生单接口,在这个方法里面,你要插入订单表,减库存,走支付,发短信等.这些工作一般都在一个方法里面写完.

修改订单的时候,你要改订单表,加减库存,走支付,发短信等,删除订单其实也是一样.

 

这时候,我们可以把发短信,支付,减库存的内容都做成事件处理者,生成接口作为一个事件触发者,生成接口抛出一个生单事件,事件广播者,就会调用所有的事件处理者,发短信的处理者,会接收成单事件,修改订单事件等各种事件,再根据数据库里面的内容不同,发不同的短信.支付接口也是一样.

这样,我们不同的业务逻辑的接发点不用搞得到处都是,而是写在一处.

 

这种模式的另一种思路是,事件触发者,流程控制者,事件处理者,就上一种思路来看,如果我们的短信需要等扣款成功后再发,那么我们如何实现呢,我们可以做一个叫扣款成功后发短信的事件,由支付系统完成工作后来触发,短信系统来接收,这样,我们的流程就表现在事件的设计上,就会有支付前短信,支付后短信,等等一堆事件,如果流程复杂了,我们的事件也会很复杂.

 

第二种变种,是指,事件触发者,发送事件,事件广播给处理者,这时,有一个流程控制器会拿到这个事件,由它来决定给哪个处理者处理,这时,这种处理者一般都直接接收事件,而是接收流程控制器的指令,这一般都是靠队列来实现.处理者完成任务后,还要再发事件出去.让流程控制器走下一个流程.

 

对于一个复杂的系统,我们可以用以下的结构给拆分出来

 

多事件触发点  一个事件广播   一个流程控制器 多个无序事件处理器  多个流程事务处理器

 

比如,我们下一张订单   如果会一定发短信的话,就做个短信事件处理器 一定会写日志的话,就做个日志事件处理器  同时流程控制器来处理流程 会有支付事件处理 库存事件处理等等

 

关于事件广播器,简单的可以做成webservice ,复杂的做成window服务,用remoting,我回头研究一下wcf是否可以监听别的端口,事件处理可能要有很多列队

列队的控制也是门技术

 

另外,如果有即时业务的话,我们还是要用过程方式的做.

 

当然,这种东西,只适合比较有钱,而代码又多到不好管理的公司,一般来讲,越是动态的东西,走的路越多,越是死的东西,走的路越秒,这种模式,想想就要几个列队,几个监听,因为是基于事件,或消息,所以又要有多次数据库查询,但写死了,可以会有比较高较的方法.所以,要看公司所需.

 

另外,因为队列,在流程事件处理上,已经可以实现分布式,如果广播器用wcf,那么,一是好用,二是分布式也好架构,事件处理器,也可以是WCF,全WCF,可以全分布式,当然,这里的HTTP消耗也是挺多的,要计算好软件寿命和各种边界了.