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

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

利用Asp.Net Core的MiddleWare思想处理复杂业务流程的更多相关文章

  1. 在ASP.NET Core使用Middleware模拟Custom Error Page功能

    一.使用场景 在传统的ASP.NET MVC中,我们可以使用HandleErrorAttribute特性来具体指定如何处理Action抛出的异常.只要某个Action设置了HandleErrorAtt ...

  2. ASP.NET Core中间件(Middleware)实现WCF SOAP服务端解析

    ASP.NET Core中间件(Middleware)进阶学习实现SOAP 解析. 本篇将介绍实现ASP.NET Core SOAP服务端解析,而不是ASP.NET Core整个WCF host. 因 ...

  3. ASP.NET Core中Middleware的使用

    https://www.cnblogs.com/shenba/p/6361311.html   ASP.NET 5中Middleware的基本用法 在ASP.NET 5里面引入了OWIN的概念,大致意 ...

  4. [转]在ASP.NET Core使用Middleware模拟Custom Error Page功能

    本文转自:http://www.cnblogs.com/maxzhang1985/p/5974429.html 阅读目录 一.使用场景 二..NET Core实现 三.源代码 回到目录 一.使用场景 ...

  5. Asp.Net Core Authentication Middleware And Generate Token

    .mytitle { background: #2B6695; color: white; font-family: "微软雅黑", "宋体", "黑 ...

  6. ASP.NET Core 入门教程 9、ASP.NET Core 中间件(Middleware)入门

    一.前言 1.本教程主要内容 ASP.NET Core 中间件介绍 通过自定义 ASP.NET Core 中间件实现请求验签 2.本教程环境信息 软件/环境 说明 操作系统 Windows 10 SD ...

  7. ASP.NET Core -中间件(Middleware)使用

    ASP.NET Core开发,开发并使用中间件(Middleware). 中间件是被组装成一个应用程序管道来处理请求和响应的软件组件. 每个组件选择是否传递给管道中的下一个组件的请求,并能之前和下一组 ...

  8. 如何设计出和 ASP.NET Core 中 Middleware 一样的 API 方法?

    由于笔者时间有限,无法写更多的说明文本,且主要是自己用来记录学习点滴,请谅解,下面直接贴代码了(代码中有一些说明): 01-不好的设计 代码: using System; namespace Desi ...

  9. ASP.NET Core 入门笔记10,ASP.NET Core 中间件(Middleware)入门

    一.前言 1.本教程主要内容 ASP.NET Core 中间件介绍 通过自定义 ASP.NET Core 中间件实现请求验签 2.本教程环境信息 软件/环境 说明 操作系统 Windows 10 SD ...

随机推荐

  1. 解决iframe在移动端(主要iPhone)上的问题

    前言 才发现已经有一段时间没有写博客了,就简单的说了最近干了啥吧.前段时间忙了杂七杂八的事情,首先弄了个个人的小程序,对的,老早就写了篇从零入手微信小程序开发,然后到前段时间才弄了个简单的个人小程序, ...

  2. QUIC协议的分析,性能测试以及在QQ会员实践

    WeTest 导读 你听过HTTPS.HTTP2.0.SPDY,但是这些应用层协议都是基于可靠的传输层协议TCP来实现的.那么,基于高效的UDP协议有没有一种相对可靠的应用层协议呢? Why QUIC ...

  3. Android自动化框架介绍

    随着Android应用得越来越广,越来越多的公司推出了自己移动应用测试平台.例如,百度的MTC.东软易测云.Testin云测试平台…….由于自己所在项目组就是做终端测试工具的,故抽空了解了下几种常见的 ...

  4. MySQL无法存储emoji表情方案

    今天学习爬虫爬伯乐在线的文章,由于在文章中有emoji表情,导致有emoji表情的文章都爬取不下来 经过一番搜索之后终于解决了问题. 原文可参考: 1. MySQL无法存储Emoji表情问题 2. m ...

  5. robot framework之弹出窗口的处理关键字实战

    1.1  弹出窗口的处理关键字 5.8.1 Alert Should Be Present关键字 按F5 查看Alert Should Be Present关键字的说明,如下图

  6. DX11 Without DirectX SDK--03 渲染一个立方体

    回到 DirectX11--使用Windows SDK来进行开发 一个立方体有8个顶点,然而绘制一个立方体需要画12个三角形,如果按照前面的方法绘制的话,则需要提供36个顶点,而且这里面的顶点数据会重 ...

  7. [ 搭建Redis本地服务器实践系列 ] :序言

    说起来,是在一个气候适宜的下午,虽然临近下班,不过办公室里还是充满了忙碌的身影,不时的还会从办公区传来小伙伴们为了一个需求而激烈争论的声音,自从入了互联网这个行业,说实话,也就很少休息了,当然了也不全 ...

  8. [Mysql]——通过例子理解事务的4种隔离级别(转)

    SQL标准定义了4种隔离级别,包括了一些具体规则,用来限定事务内外的哪些改变是可见的,哪些是不可见的. 低级别的隔离级一般支持更高的并发处理,并拥有更低的系统开销. 一.事务隔离级别分类 第1级别:R ...

  9. springboot+mybatis+ehcache实现缓存数据

    一.springboot缓存简介 在 Spring Boot中,通过@EnableCaching注解自动化配置合适的缓存管理器(CacheManager),Spring Boot根据下面的顺序去侦测缓 ...

  10. linux模块驱动之led(ioremap)

    一:led内核驱动 (1)在编写led内核驱动时,我们首先要进行内核裁剪,因为友善之臂将LED灯的驱动默认加载到内核中,所以编写模块驱动程序前就要先把原先的LED灯驱动裁剪掉: led驱动在源码里面的 ...