利用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)

相关推荐

  • ASP.NET Core应用错误处理之DeveloperExceptionPageMiddleware中间件呈现“开发者异常页面”

    前言 在<ASP.NET Core应用的错误处理[1]:三种呈现错误页面的方式>中,我们通过几个简单的实例演示了如何呈现一个错误页面,这些错误页面的呈现分别由三个对应的中间件来完成,接下来我们将对这三个中间件进行详细介绍.在开发环境呈现的异常页面是通过一个类型为DeveloperExceptionPageMiddleware中间件实现的. public class DeveloperExceptionPageMiddleware { public DeveloperExceptionPageM

  • ASP.NET Core应用错误处理之StatusCodePagesMiddleware中间件针对响应码呈现错误页面

    前言 StatusCodePagesMiddleware中间件与ExceptionHandlerMiddleware中间件比较类似,它们都是在后续请求处理过程中"出错"的情况下利用一个错误处理器来完成最终的请求处理与响应的任务.它们之间的差异在于对"错误"的界定上,对于ExceptionHandlerMiddleware中间件来说,它所谓的错误就是抛出异常,但是对于StatusCodePagesMiddleware中间件来说,则将介于400~599之间的响应状态码视

  • ASP.NET Core应用错误处理之ExceptionHandlerMiddleware中间件呈现“定制化错误页面”

    前言 DeveloperExceptionPageMiddleware中间件利用呈现出来的错误页面实现抛出异常和当前请求的详细信息以辅助开发人员更好地进行纠错诊断工作,而ExceptionHandlerMiddleware中间件则是面向最终用户的,我们可以利用它来显示一个友好的定制化的错误页面.按照惯例,我们还是先来看看ExceptionHandlerMiddleware的类型定义. public class ExceptionHandlerMiddleware { public Excepti

  • ASP.NET Core Middleware的实现方法详解

    概念 ASP.NET Core Middleware是在应用程序处理管道pipeline中用于处理请求和操作响应的组件. 每个组件: 在pipeline中判断是否将请求传递给下一个组件 在处理管道的下个组件执行之前和之后执行一些工作, HttpContxt对象能跨域请求.响应的执行周期 特性和行为 ASP.NET Core处理管道由一系列请求委托组成,一环接一环的被调用, 下面给出自己绘制的Middleware pipeline流程图: 从上图可以看出,请求自进入处理管道,经历了四个中间件,每个

  • 利用Asp.Net Core的MiddleWare思想如何处理复杂业务流程详解

    前言 最近利用Asp.Net Core 的MiddleWare思想对公司的古老代码进行重构,在这里把我的设计思路分享出来,希望对大家处理复杂的流程业务能有所帮助. 背景 一个流程初始化接口,接口中根据传入的流程类型,需要做一些不同的工作. 1.有的工作是不管什么类型的流程都要做的(共有),有的工作是某一流程特有的. 2.各个处理任务基本不存在嵌套关系,所以代码基本是流水账式的. 3.流程的种类较多,代码中if或者switch判断占了很大的篇幅. 4.这些处理工作大致可分为三大类,前期准备工作(参

  • ASP.NET Core扩展库之实体映射使用详解

    在分层设计模式中,各层之间的数据通常通过数据传输对象(DTO)来进行数据的传递,而大多数情况下,各层数据的定义结构大同小异,如何在这些定义结构中相互转换,之前我们通过使用AutoMapper库,但AutoMapper功能庞大,使用较为复杂,而在很多场景下,可能我们只需要一些基础的对象映射功能,那么此时你可以选择扩展库中的轻量级AutoMapper实现. 实体映射包含以下核心功能: 在使用之前无需手动定义类型之间的映射关系 采用动态编译.缓存转换委托,提升性能. 支持通过特性定义属性映射关系 支持

  • ASP.NET Core中间件计算Http请求时间示例详解

    ASP.NET Core通过RequestDelegate这个委托类型来定义中间件 public delegate Task RequestDelegate(HttpContext context); 可将一个单独的请求委托并行指定为匿名方法(称为并行中间件),或在类中对其进行定义.可通过Use,或在Middleware类中配置要传递给委托执行的方法(参数类型HttpContext,返回值类型Task). public static IApplicationBuilder Use(this IA

  • ASP.NET Core程序发布到Linux生产环境详解

    在这篇文章里我们将介绍如何在 Ubuntu 14.04 Server上部署ASP.NET Core应用程序.我们将把ASP.NET Core应用程序放到一个反向代理服务器的后面,由代理服务器把请求转交给我们的Kestrel服务器.除此之外,我们还将保证我们的web应用程序作为一个守护进程来进行启动.我们需要配置一个进程管理工具来帮助我们在程序崩溃时恢复程序,以保证高可用性. 章节: 准备 复制你的应用程序 配置一个反向代理服务器 监控我们的应用程序 启动我们的应用程序 观察日志 使我们的应用程序

  • ASP.NET Core 2.2中的Endpoint路由详解

    Endpoint路由 在ASP.NET Core 2.2中,新增了一种路由,叫做 Endpoint (终结点)路由.本文将以往的路由系统称为 传统路由 . 本文通过源码的方式介绍传统路由和 Endpoint 路由部分核心功能和实现方法,具体功能上的差异见 官方文档 . 在升级到ASP.NET Core 2.2后,会自动启用 Endpoint 路由.如果要恢复以往的实现逻辑,需要加入以下代码: services.AddMvc(options => options.EnableEndpointRou

  • ASP.NET Core学习之使用JWT认证授权详解

    概述 认证授权是很多系统的基本功能 , 在以前PC的时代 , 通常是基于cookies-session这样的方式实现认证授权 , 在那个时候通常系统的用户量都不会很大, 所以这种方式也一直很好运行, 随着现在都软件用户量越来越大, 系统架构也从以前垂直扩展(增加服务器性能) -> 水平扩展(增加服务器数量) cookies-session 工作方式 客户端提交用户信息 -> 服务器识别用户 -> 服务端保存用户信息 -> 返回session-id客户端 -> 客户端保存ses

  • Asp.net core 使用SignalR推送消息过程详解

    1).SignalR简介 ASP.NET Core SignalR 是为 ASP.NET 开发人员提供的一个库,可以简化开发人员将实时 Web 功能添加到应用程序的过程. 实时 Web 功能是指这样一种功能:当所连接的客户端变得可用时服务器代码可以立即向其推送内容,而不是让服务器等待客户端请求新的数据. 2).SignalR主要用途: 它出现的主要用途:可以用在聊天室.Web实时推送消息 (Real-Push-Message).单点和多点通讯.扫码登陆.甚至可以结合其他技术用来做视频聊天等等.

  • 理解ASP.NET Core 中间件(Middleware)

    目录 中间件 中间件管道 Run Use UseWhen Map MapWhen Run & Use & UseWhen & Map & Map 编写中间件并激活 基于约定的中间件 基于工厂的中间件 基于约定的中间件 VS 基于工厂的中间件 中间件 先借用微软官方文档的一张图: 可以看到,中间件实际上是一种配置在HTTP请求管道中,用来处理请求和响应的组件.它可以: 决定是否将请求传递到管道中的下一个中间件 可以在管道中的下一个中间件处理之前和之后进行操作 此外,中间件的注

  • C#利用ASP.NET Core开发学生管理系统详解

    目录 涉及知识点 创建项目 登录模块 1. 创建控制器--LoginController 2. 创建登录视图 3. 创建用户模型 4. 创建数据库操作DataContext 5. 创建数据库和表并构造数据 6. 添加数据库连接配置 7. 添加注入信息 8. 运行测试 随着技术的进步,跨平台开发已经成为了标配,在此大背景下,ASP.NET Core也应运而生.本文主要利用ASP.NET Core开发一个学生管理系统为例,简述ASP.NET Core开发的常见知识点,仅供学习分享使用,如有不足之处,

  • 详解ASP.NET Core中间件Middleware

    本文为官方文档译文,官方文档现已非机器翻译 https://docs.microsoft.com/zh-cn/aspnet/core/fundamentals/middleware/?view=aspnetcore-2.1 什么是中间件(Middleware)? 中间件是组装到应用程序管道中以处理请求和响应的软件. 每个组件: 选择是否将请求传递给管道中的下一个组件. 可以在调用管道中的下一个组件之前和之后执行工作. 请求委托(Request delegates)用于构建请求管道,处理每个HTT

随机推荐