日期：2022年 06月 20日

標籤： C# Asp.NET Framework

摘要：C# 學習筆記

第一部分：問題說明與範例主專案介紹

Step 1：代碼範例中的專案架構

專案大致分成四個區塊
1：基底類，基本的繼承與原本主程式的OnException
2：Controller，API位址，範例有3個API在該檔案
3：BusinessService，由Controller中觸發錯誤的訊息的主程式
4：View，顯示畫面用

Step 2：執行程式，原本的結果-1

執行後，點擊 “錯誤函式A” 的按鈕

Step 3：執行程式，原本的結果-2

網址列會有錯誤訊息
※這邊做示範，真正網站通常該透過Restful API取得對應資料

Step 4：執行程式，觸發過程

1. 當頁面點擊時，呼叫到API
   2. API會呼叫Service 觸發錯誤訊息
   3. 最後將錯誤訊息返回到網址列
   
   
   

Step 5：找出改動的標的

看到HomeController 上有基底的FoundationController 繼承，F12跳轉查看
1. 圖片中黃框Step1、Step2-1、Step2-2，是觸發Exception並且往前端傳訊息的地方
2. API執行開始時
3. API執行結束時
所以調整的目標為 Step2-1 與 Step2-2 ，返回前端錯誤訊息時

第二部分：不影範例主專案的代碼調整方式

Step 1：調整基底代碼

1. 新增客製化的錯誤訊息替換的代碼，接收Exception的錯誤訊息，然後替換
   2. Json捕捉到錯誤訊息 filterContext.Exception.Message 替換後放到正確的Json位置
   3. API捕捉到錯誤訊息 filterContext.Exception.Message 替換後放到正確的網址列上
   
   
   

Step 2：替換錯誤訊息主流程

替換錯誤訊息的主流程如下
1. 新建一個新的檔案 ReplaceErrorMessage然後呼叫裡面的Method
2. 新建的檔案裡面有一Method 為 GlobalReplaceErrorMessage() 所有替換的錯誤訊息都透過該方法
3. 不影響原本的Service 所以建立1對1的Service做對映

Step 3：實際替換代碼實現流程-1

1. 需要替換的方法需要建立對映字典表，Key為原本的 命名空間 + MethodName；Value則為實現替換的Func(Method方法)
   2. 找出ExceptionContext 中當前發生錯誤的Service位址(命名空間+MethodName)
   
   
   

Step 4：實際替換代碼實現流程-2

補充找出當前錯誤訊息Serivce的命名空間 +MethodName的方法，透過正則表達式

//Regular Expression 找出當前查詢的真實的Business MethodName
string ParseCurrentMethodName(string input)
{
    var result = string.Empty;
    var regexPattern = @"(<.+>)";
    var coll = Regex.Match(input, regexPattern);
    if (coll.Groups.Count > 0)
    {
        input = coll.Groups[0].Value;
        var regexPattern2 = "\\w+";
        var coll2 = Regex.Match(input, regexPattern2);
        if (coll2.Groups.Count > 0)
        {
            result = coll2.Groups[0].Value;
        }
    }
    return result;
}

Step 5：新建對映替換錯誤訊息的Serivce

1. MapperErrorMessage為新建的替換錯誤訊息檔案
   2. 原本的Service，不可以異動，可以想像成引用外部的.dll檔案
   3. 新建的替換錯誤訊息Service，可以依照對映錯誤訊息替換
   
   
   

第三部分：調整後結果與補充

Step 1：調整後的結果

如圖，錯誤訊息已經變成自製錯誤訊息，並且不改動原本的Service

Step 2：補充-為何新建ReplaceErrorMessage的檔案

為何新建ReplaceErrorMessage的檔案方法，而不寫在Foundation中的CoustomerExceptionMessage Method中
如下圖，如果少了Common的ReplaceErrorMessage這一檔案，而寫在CoustomerExceptionMessage()中，2點理由：
1. FoudationController負責的事務邏輯更複雜，除了原本的Exception Override外，還要處理所有替換的檔案
2. 維護性，未來若Mapper替換錯誤訊息的代碼要調整，會改到FoundationController的檔案

Step 3：補充-為何要字典表對映

如下圖，字典表對映的Key，為原本的程式碼與Method
未來若某個原始功能不使用了，會將原本的程式碼移除，此時建置字典表_registErrorMessageMappingDictionary必定會初始化報錯
表示原始功能移除，對映的替換錯誤訊息Service也可以一並移除，因此可增加系統維護性