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

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对的支持。