利用Asp.Net Core的MiddleWare思想如何处理复杂业务流程详解
前言
最近利用asp.net core 的middleware思想对公司的古老代码进行重构,在这里把我的设计思路分享出来,希望对大家处理复杂的流程业务能有所帮助。
背景
一个流程初始化接口,接口中根据传入的流程类型,需要做一些不同的工作。
1.有的工作是不管什么类型的流程都要做的(共有),有的工作是某一流程特有的。
2.各个处理任务基本不存在嵌套关系,所以代码基本是流水账式的。
3.流程的种类较多,代码中if或者switch判断占了很大的篇幅。
4.这些处理工作大致可分为三大类,前期准备工作(参数的校验等),处理中的工作(更新数据库,插入数据等),扫尾工作(日志记录,通知等)
asp.net core中的middleware
注意第二条,流水账式的代码,这让我想到《管道模型》,而asp.net core的middleware正是放在这个管道中的。
看下图:
有middleware1,middleware2,middleware3这三个中间件放在一个中间件的集合(pipeline,管道)中并有序排列,request请求1从流向2载流向3,随之产生的response从底层依此流出。
这个request和resopnse就封装在我们经常看到的context上下文中,context传入到中间件1,中间件1处理后再传出context给中间件2 >>>> 一直这样传出去,直到传到最后一个。
我们经常在startup的configure中调用的app.use()方法,其实也就是向这个集合中添加一个middleware,context进入后,必须被该middleware处理。
不知道我这么说,大家有没有这种管道模型处理任务的概念了?
代码解读
不懂?没关系,那我们结合代码看看。
上面说过,每个middleware会把context从自己的身体里面过一遍并主动调用下一个中间件。
所以,中间件是什么? 是一个传入是context,传出也是context的方法吗?不是!
是一个传入是委托,传出也是委托,而这传入传出的委托的参数是context,该委托如下:
/// <summary> /// 管道内的委托任务 /// </summary> /// <param name="context"></param> /// <returns></returns> public delegate task pipelinedelegate<in tcontext>(tcontext context);
所以中间件是下面这样的一个func,它肩负起了调用下一个中间件(委托)的重任:
func<pipelinedelegate<tcontext>, pipelinedelegate<tcontext>>
而管道又是什么呢? 是func的集合,如下:
ilist<func<pipelinedelegate<tcontext>, pipelinedelegate<tcontext>>> _components = new list<func<pipelinedelegate<tcontext>, pipelinedelegate<tcontext>>>();
我们再startup方法里面的configure方法里面的use是在做什么呢?其实就是在给上面的管道_components添加一个func,如下:
public ipipelinebuilder<tcontext> use(func<pipelinedelegate<tcontext>, pipelinedelegate<tcontext>> func) { _components.add(func); return this; }
但是在今天的use中呢,我还想对原有的use进行一次重载,如下:
public ipipelinebuilder<tcontext> use(action<tcontext> action, int? index = null) { func<pipelinedelegate<tcontext>, pipelinedelegate<tcontext>> pipledelegate = next => { return context => { action.invoke(context); return next.invoke(context); }; }; if (index.hasvalue) if (index.value > _components.count) throw new exception("插入索引超出目前管道大小"); else { _components.insert(index.value, pipledelegate); } else { _components.add(next => { return context => { action.invoke(context); return next.invoke(context); }; }); } return this; }
可以看到,重载之后,传入的变成了action<tcontext> action,因为我想外部专注于自己要真正处理的业务,而调用下一个middleware的事情封装到方法内部,不用外部来关心了,并且,可以通过传入的index指定插入的中间件的位置,以此来控制业务的执行顺序。
最后,需要把传入的委托链接起来,这就是管道的build工作,代码如下:
public pipelinedelegate<tcontext> build() { var requestdelegate = (pipelinedelegate<tcontext>)(context => task.completedtask); foreach (var func in _components.reverse()) requestdelegate = func(requestdelegate); return requestdelegate; }
到这里,管道相关的差不多说完了,那我,我如何利用上面的思想来处理我的业务呢?
处理业务
处理示意图
步骤:
ø 初始化三条处理管道(根本是new三个list<task>集合,对应前期准备工作集合,处理中工作的集合,扫尾工作的集合)。
ø 向三条管道中注入公共的处理任务。
ø 根据传入的流程类型动态加载对应的处理方法handle()。
ø handle方法向三条管道中注入该类型的流程所对应的特有任务。
ø build三条管道。
ø 依此执行准备工作管道=>处理中管道=>处理后管道。
上面步骤可以概括成下面的代码。
private void initapproveflow(approveflowinitcontext context) { var beforepipelinebuilder = initbeforepipeline(); var handlingpipelinebuilder = inithandlingpipeline(); var afterpipelinebuilder = initafterpipeline(); registerentitypipeline(context.flowtype, beforepipelinebuilder, handlingpipelinebuilder, afterpipelinebuilder); var beforepipeline = beforepipelinebuilder.build(); var handlingpipeline = handlingpipelinebuilder.build(); var afterpipeline = afterpipelinebuilder.build(); beforepipeline.invoke(context); handlingpipeline.invoke(context); afterpipeline.invoke(context); }
其中,registerentitypipline()方法根据flowtype动态加载对应的类,所有类继承了一个公共的接口,接口暴露出了handle方法。
private void registerentitypipeline(string flowtype, ipipelinebuilder<approveflowinitcontext> beforepipelinebuilder, ipipelinebuilder<approveflowinitcontext> handlingpipelinebuilder, ipipelinebuilder<approveflowinitcontext> afterpipelinebuilder) { var handleclassname = ("类名的前缀" + flowtype).tolower(); var type = appdomain.currentdomain.getassemblies() .where(a => a.fullname.contains("程序及名称")) .selectmany(a => a.gettypes().where(t => t.getinterfaces().contains(typeof(类继承的接口名称)) ) ).firstordefault(u => u.fullname != null && u.name.tolower() == handleclassname ); if (type == null) throw new objectnotfoundexception("未找到名称为[" + handleclassname + "]的类"); var handle = (类继承的接口名称)_serviceprovider.getservice(type); handle.handle(beforepipelinebuilder, handlingpipelinebuilder, afterpipelinebuilder); }
handle方法里面又做了什么呢?
public void handle(ipipelinebuilder<approveflowinitcontext> beforepipelinebuilder, ipipelinebuilder<approveflowinitcontext> handlingpipelinebuilder, ipipelinebuilder<approveflowinitcontext> afterpipelinebuilder) { handlebefore(beforepipelinebuilder); handling(handlingpipelinebuilder); handleafter(afterpipelinebuilder); }
分别向三个管道中添加 前、中、后 对应的任务。
q&a
q1:如果处理任务依赖于上一个处理任务的处理结果怎么办?
pipelinedelegate<tcontext> 中的tcontext是一个对象,可以向该对象中添加对应的属性,上游任务处理任务并对context中的属性赋值,供下游的任务使用。
q2:如果某一个任务需要在其他任务之前执行怎么办(需要插队)?
pipelinebuilder.use() 中,有index参数,可以通过该参数,指定插入任务的位置。
q3:如果保证管道的通用性(不局限于某一业务)?
tcontext是泛型,可以不同的任务创建一个对应的tcontext即可实现不同业务下的pipleline的复用。
总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对的支持。
上一篇: SQL查询连续号码段的巧妙解法
下一篇: smarty中post用法实例