利用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的复用。

有什么上面没涉及的问题欢迎大家在下方留言提问,谢谢。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Kevin-ZhangCG

Java开发岗面试知识点解析

395110
来自专栏程序员与猫

Go Code Review Comments 译文(截止2018年7月27日)

持续更新中… 原文最新链接 https://github.com/golang/go/wiki/CodeReviewComments/5a40ba36d38...

24230
来自专栏木宛城主

Unity应用架构设计(10)——绕不开的协程和多线程(Part 1)

在进入本章主题之前,我们必须要了解客户端应用程序都是单线程模型,即只有一个主线程(Main Thread),或者叫做UI线程,即所有的UI控件的创建和操作都是...

41360
来自专栏技术小黑屋

关于对象池的一些分析

在日常的开发工作中,我们可能使用或者听说过对象池,线程池以及连接池。本文将介绍对象池的产生缘由,具体实现细节,以及需要注意的问题。

23610
来自专栏码农阿宇

利用Asp.Net Core的MiddleWare思想处理复杂业务流程

最近利用Asp.Net Core 的MiddleWare思想对公司的古老代码进行重构,在这里把我的设计思路分享出来,希望对大家处理复杂的流程业务能有所帮助。

10610
来自专栏文大师的新世界

Java面试

自己经验有限,篇幅也有限,这里只是记录一些比较容易混淆或有难度和一些易忘的技术知识点,里面有一些也是面试阿里经常会被问到的问题,但是不保证答案全部正确,有错误的...

27030
来自专栏宋凯伦的技术小栈

[一个小问题]Mainfest配置文件的version问题小结

  问题起源自己安装好产品的新build,然后用自己本地编译出来的其中一个DLL去替换到产品中,本来以为可以正常执行,但是却发现这个新DLL无法被Load,无法...

202100
来自专栏老司机的简书

老司机读书笔记——Effective Objective-C 2.0阅读笔记

比方说,在循环中不断地创建的临时对象。即便这些对象在调用完方法之后就就不在使用了,他们也依然处于存活状态,因为目前还在自动释放池里,等待系统稍后将其释放并回收。...

10320
来自专栏一名叫大蕉的程序员

您需要来一份82年的代理吗?No.12

上一篇大家又说我放水了。这样说我很伤心的啵。今天跟大家分享一下代理模式以及JAVA中的代理模式。 代理模式有什么用呢?我总结的一点就是,让别人代理安全一点。 现...

19670
来自专栏漏斗社区

CTF| SQL注入之login界面

SQL注入是CTF WEB方向必不可少的一种题型,斗哥最近也做了一些在线题目,其中最常见的题目就是给出一个登录界面,让我们绕过限制登录或者一步步注入数据。 万...

2.7K80

扫码关注云+社区

领取腾讯云代金券