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

 

有什麼上面沒涉及的問題歡迎你們在下方留言提問，謝謝。