最近利用Asp.Net Core 的MiddleWare思想对公司的古老代码进行重构,在这里把个人设计思路分享出来,但愿对你们处理复杂的流程业务能有所帮助。数据库
背景app
一个流程初始化接口,接口中根据传入的流程类型,须要作一些不一样的工做。ide
1.有的工做是无论什么类型的流程都要作的(共有),有的工做是某一流程特有的。ui
2.各个处理任务基本不存在嵌套关系,因此代码基本是流水帐式的。this
3.流程的种类较多,代码中if或者switch判断占了很大的篇幅。spa
4.这些处理工做大体可分为三大类,前期准备工做(参数的校验等),处理中的工做(更新数据库,插入数据等),扫尾工做(日志记录,通知等)设计
Asp.Net Core中的MiddleWare日志
注意第二条,流水帐式的代码,这让我想到《管道模型》,而Asp.Net Core的MiddleWare正是放在这个管道中的。code
看下图:component
有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的复用。
有什么上面没涉及的问题欢迎你们在下方留言提问,谢谢。