前言
最近利用Asp.Net Core 的MiddleWare思想對公司的古老代碼進行重構，在這里把我的設計思路分享出來，希望對大家處理復雜的流程業(yè)務能有所幫助。
背景
一個流程初始化接口，接口中根據(jù)傳入的流程類型，需要做一些不同的工作。
1.有的工作是不管什么類型的流程都要做的（共有），有的工作是某一流程特有的。
2.各個處理任務基本不存在嵌套關系，所以代碼基本是流水賬式的。
3.流程的種類較多，代碼中if或者switch判斷占了很大的篇幅。
4.這些處理工作大致可分為三大類，前期準備工作（參數(shù)的校驗等），處理中的工作（更新數(shù)據(jù)庫，插入數(shù)據(jù)等），掃尾工作（日志記錄，通知等）
Asp.Net Core中的MiddleWare
注意第二條，流水賬式的代碼，這讓我想到《管道模型》，而Asp.Net Core的MiddleWare正是放在這個管道中的。
看下圖：
有middleware1,middleware2,middleware3這三個中間件放在一個中間件的集合（PipeLine，管道）中并有序排列，Request請求1從流向2載流向3，隨之產(chǎn)生的Response從底層依此流出。
這個Request和Resopnse就封裝在我們經(jīng)常看到的Context上下文中，Context傳入到中間件1，中間件1處理后再傳出Context給中間件2 >>>> 一直這樣傳出去，直到傳到最后一個。
我們經(jīng)常在startup的configure中調(diào)用的app.use()方法，其實也就是向這個集合中添加一個middleware,Context進入后，必須被該middleware處理。
不知道我這么說，大家有沒有這種管道模型處理任務的概念了？
代碼解讀
不懂？沒關系，那我們結合代碼看看。
上面說過，每個MiddleWare會把Context從自己的身體里面過一遍并主動調(diào)用下一個中間件。
所以，中間件是什么？ 是一個傳入是Context,傳出也是Context的方法嗎？不是！
是一個傳入是委托，傳出也是委托，而這傳入傳出的委托的參數(shù)是Context,該委托如下：
|
1
2
3
4
5
6
|
/// <summary> /// 管道內(nèi)的委托任務 /// </summary> /// <param name="context"></param> /// <returns></returns> public delegate Task PipeLineDelegate<in TContext>(TContext context); |
所以中間件是下面這樣的一個Func，它肩負起了調(diào)用下一個中間件（委托）的重任：
|
1
|
Func<PipeLineDelegate<TContext>, PipeLineDelegate<TContext>> |
而管道又是什么呢？ 是Func的集合，如下：
|
1
|
IList<Func<PipeLineDelegate<TContext>, PipeLineDelegate<TContext>>> _components = new List<Func<PipeLineDelegate<TContext>, PipeLineDelegate<TContext>>>(); |
我們再Startup方法里面的Configure方法里面的Use是在做什么呢？其實就是在給上面的管道_components添加一個func,如下：
|
1
2
3
4
5
|
public IPipeLineBuilder<TContext> Use(Func<PipeLineDelegate<TContext>, PipeLineDelegate<TContext>> func) { _components.Add(func); return this; } |
但是在今天的Use中呢，我還想對原有的Use進行一次重載，如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
|
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，因為我想外部專注于自己要真正處理的業(yè)務，而調(diào)用下一個middleware的事情封裝到方法內(nèi)部，不用外部來關心了，并且，可以通過傳入的index指定插入的中間件的位置，以此來控制業(yè)務的執(zhí)行順序。
最后，需要把傳入的委托鏈接起來，這就是管道的Build工作，代碼如下：
|
1
2
3
4
5
6
7
8
9
|
public PipeLineDelegate<TContext> Build() { var requestDelegate = (PipeLineDelegate<TContext>)(context => Task.CompletedTask); foreach (var func in _components.Reverse()) requestDelegate = func(requestDelegate); return requestDelegate; } |
到這里，管道相關的差不多說完了，那我，我如何利用上面的思想來處理我的業(yè)務呢？
處理業(yè)務
處理示意圖
步驟：
Ø 初始化三條處理管道（根本是New三個List<Task>集合，對應前期準備工作集合，處理中工作的集合，掃尾工作的集合）。
Ø 向三條管道中注入公共的處理任務。
Ø 根據(jù)傳入的流程類型動態(tài)加載對應的處理方法Handle()。
Ø Handle方法向三條管道中注入該類型的流程所對應的特有任務。
Ø Build三條管道。
Ø 依此執(zhí)行準備工作管道=>處理中管道=>處理后管道。
上面步驟可以概括成下面的代碼。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
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()方法根據(jù)flowType動態(tài)加載對應的類，所有類繼承了一個公共的接口，接口暴露出了Handle方法。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
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方法里面又做了什么呢？
|
1
2
3
4
5
6
|
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:如果某一個任務需要在其他任務之前執(zhí)行怎么辦（需要插隊）？
PipeLineBuilder.Use() 中，有Index參數(shù)，可以通過該參數(shù)，指定插入任務的位置。
Q3:如果保證管道的通用性（不局限于某一業(yè)務）？
TContext是泛型，可以不同的任務創(chuàng)建一個對應的TContext即可實現(xiàn)不同業(yè)務下的PipleLine的復用。
總結
以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對服務器之家的支持。
原文鏈接：https://www.cnblogs.com/CoderAyu/p/9452444.html
