.NET 使用 Link CS檔案的型別比較的捉鬼記

圖片取自：https://home.gamer.com.tw/creationDetail.php?sn=2461568

前言

最近擔任某產業的 Redis 導入的執行顧問，我的任務就是，協助將 Redis 導入在既有的系統裡，在這個顧問案裡面，我遇到的挑戰是：

  • 現有系統使用某產品進行開發（好處是個系統共用此平台 Platform 提供的服務／壞處是某處出現問題就會全部一起死）
  • 現有系統使用 .NET 4.0 的 Object Cache、所以要全部上 Redis，但是 Object Cache 是撰寫在該產品平台 Platform 內 Kernel 所提供的功能之一，我得協助修改核心 Kernel 的 Cache Provider
  • 另外是，系統為 ASP.NET WebForm ，所以許多存放在 Cache 內的資料均為 DataSet（基於一些原因我無法全改為不使用 DataSet），但因為我們知道 DataSet 並無法直接序列化轉為 Redis 可接受的格式，所以我得做些手腳以協助將這些資料轉換為 Redis 可以接受的格式
  • 有上千隻程式運行在上面、必須一氣呵成！
  • 包含伺服器主機架構規劃 [建置 HA 高可用性架構]（必須購置新主機），所以也包含硬體規格建議等等

開始

這個案子在開始之前，最麻煩之處、也比較有代表性工作在於：

  1. Code-Review 包括現有平台 Platform & 子系統
  2. 改寫現有平台原始程式碼 & 包括最主要的 Cache Provider
  3. 以隔離測試（Isolation Unit Test）方法來進行改寫

進行 Code-Review 的部分比須帶著團隊來進行，當然包括 IntelliSys 平台的維護者，因為我需要了解現有的架構規劃、現有的 Cache 的使用情況、與現有 Cache 策略使用規劃等等、接著就是評估修改的幅度 與 範圍，因為程式修改的部分還是得以專案形式來進行，我還是會估一個類似 WBS 的工時並提供給客戶。

實際進行時，我大約花了 1 天的時間，對！幾乎一整天的時間，看了整個 IntelliSys 幾近所有的程式碼，因為為了較精準的估花費時間，也是因為客戶要求。第二天便開始架設 Redis 環境，第三天開始修改程式碼。

以 Unit Test 方式改寫 Cache Provider

此次替此客戶導入 Redis 我用了一些新的手法，當然，這也不是多新的梗、或者多新的技術，只是我利用單元測試 Unit Test 中的隔離測試 Isolation Unit Test 的一些手法將既有的 Cache Provider 隔離開來，因為目前的 code 都早已經在 Production 環境中執行了，所以必須在現有系統中移轉。

但是為了能夠一步到位，我還是要了核心需要修改的程式碼，但因為外部參考以及呼叫它的外部 Business & Services 當然是不方便給我，但其實這沒有關係，因為全部對 Cache Provider 存取的接口才是我需要考慮的，所以所有會存取 Cache Provider 的我全部的需求的角度來細切為撰寫 Unit Test 的最小粒度，所有對 Cache Provider 的外部 Class 我全部撰寫成 Fake 假物件來支撐整個單元測試。

沒錯，也就是說，我其實只拿到 CacheHelper.cs & BaseService.cs & CodeCache.cs 這三個 C# 檔案，其他的專案都是我參照現有系統架構手刻 & 撰寫起來的 Fake 假物件，大部分都是針對介面回呼 & 滿足傳回假的空殼子而已，而這全部針對與為了滿足 Redis Cache 而設計的專案結構。

圖（一）、只有紅框部分為客戶端 Cache Provider 的程式碼

所以 Unit Test 真的非常好用，以 Unit Test 為進入點的軟體架構設計也更能夠將需求單元化 & 細粒化、更容易測試的情況下、容易控制耦合性，程式碼比較容易修改，經過分析後，整個要撐起來的 CacheHelper.cs 根本也不需要知道外部環境幾乎都是假的，而我的單元測試通過之後，CacheHelper.cs 直接 Copy 到它實際的運作環境就大功告成了！

從圖（一）中可以看出來，除了 CacheHelper.cs & BaseService.cs & CodeCache.cs 這三個 C# 檔案外，其他的『專案』、『程式檔案』都是我【造】【假】出來的！ XD

圖（二）、開始撰寫單元測試

如上圖（二）、我只需要關注所有的單元測試是否成功就大功告成了，因為我基本上建造一個供 Redis Cache Provider 所需要運行的基本環境，所以完成後我只需要複製到客戶實際的環境中即可！

以上動作均在客戶的測試環境中進行。

將 DataSet 放入 Redis Cache 中

這又是另一個挑戰（但別問我為什麼要將 DataSet 置入 Redis 中），因為客戶使用 ASP.NET WebForm，在那個年代 DataSet 仍然是 .NET 離線小DB的最佳實踐，該產品在 AP 端交換的資料也都是 DataSet。

由於這也是第一次對 ASP.NET WebForm 進行 Redis 的導入，且熟悉 Redis 的朋友應該也都清楚 Redis Cache 存放的主要的內容就是字串 String，而 DataSet 雖然可以序列化為 XML，但是不是你直接標記 [Serialize] 標籤加以序列化即可，即便你將 XML 放入 Redis 中，你從 Redis 裡 Get 出來的時候型態就不是 DataSet 了，更不用說客戶還有 Typed DataSet…

那怎麼辦呢？我的解決方式是，建立一個新的型別，這個型別要能夠吃進 Typed DataSet 的 Assembly 名稱、NameSpace、Class Name 等相關資訊，當然還包括 XML Schema 資訊，所以你必須將 DataSet/Typed DataSet 拆解為這個自訂型態後再存入 Redis 中，其實存進去比較沒什麼難度，比較困難的是，取出來的時候，還得要轉換為對應型別的 Typed DataSet（這裡原生地 DataSet 反而沒什麼問題），還得透過 Assembly 的 GetType("[Namespace].[ClassName]") 來載入型別，最後還原整個 DataSet 的內容。

平行測試的插曲

這個顧問案前後我大約進行了 9 天就差不多完成了整個 （Code-Review／程式撰寫／環境安裝）等等，平行運作大致上也都沒什麼問題，雖然是 DataSet ，但是整體效能並沒有低於先前使用 .NET ObjectCache 的效能。

但是時間過了兩個禮拜，卻發現異常的情況，但是這個異常並不是隨時會發生，在某個功能會發生、某些功能又不會發生，甚至我連 Dump 檔案也建立了，透過 IntelliTrace 去看卻也看不到錯誤的堆疊，案情一整個陷入膠著狀態。

後來實在無法可想，只好利用 VS 遠端偵錯功能直接偵錯測試主機，卻讓我發現了一個驚呆了的情況：

圖（三）、表面上型別完全相同、但卻不相等的情況

如上圖（三）明明完整的 Namespace 與 Class Name 完全相同，但是程式的執行結果卻判定兩個是不同的，細看才發現兩個位於不同的組件 Assembly 中。

我突然間瞬間恍然大悟，馬上了解情況並立馬修正程式馬，馬上就修復了這個問題。

為什麼會不相等的原因呢？看我娓娓道來。

圖（四）、typeof(DataSetInRedis) 位於的組件位置

如上圖，目前的 Execute Assemblies 裡面直接 typeof(DataSetInRedis) 取的型別是位於 IntelliSys.Services 裡。

圖（五）、outputResultType 位於的組件位置

不相等的最主要原因是什麼呢？因為從 runtime 傳入到該方法中的 outputResultType 居然位於 IntelliSys.Services 中！但為什麼這兩個型別會位於不同的 Assembly 中呢？原因是因為，在 IntelliSys 的平台內使用了 Visual Studio 的 Link 程式碼的功能，這個功能是這樣的，它可以其他專案裡以 (連結) Link 的方式加入其他專案裡的程式碼檔案 (*.cs/;*.vb) 等，但對於整個方案而言，編輯的都還是同一個程式碼檔案，也就是 Shared Code 的概念，但每個專案卻以為自己獨佔這個程式碼檔案，但事實上卻是在編輯同一個檔案，且 Compile 後也是各自 Compile 到自己的 Assembly 的 Metadata 中。

下面圖（六）說明 Visual Studio 使用 Link 程式碼檔案的情況。

圖（六）、在 Visual Studio 使用 Link 程式碼檔案的情境

這種情況下，加上在原有架構下，IntelliSys.Web 與 Services 都可以同時存取 CacheProvider，如果有一個 Request 從 IntelliSys.Services 進來，但它卻因為 Entities & ViewModels 在 Application Block 區塊裡，也就是 IntelliSys.Web 層，但 IntelliSys.Services 卻使用 Assembly.Load() 動態的叫用 IntelliSys.Web 下的 Business Logic ，所以這時候的 AppDomain 其實是運作在 IntelliSys.Web 下，而當時的 Execute Assemblies 會抓到的是 IntelliSys.Web 的 DataSetInRedis 而不是 IntelliSys.Services 下面的 DataSetInRedis 物件而產生這個詭異的問題。

但因為 IntelliSys 的原始架構是如此，我只能先順應 IntelliSys 的原始架構進行修改，否則我應該得起另一個架構調整的顧問案來進行這一塊。

而修改的方式如下圖（七）

圖（七）、改以判斷 TypeName 的方式
enter image description here

但是判斷字串的方式並不是非常的理想，所以，我上次在軟體開發之路才對提到，我通常不太建議使用 Link 的方式來設計軟體架構，或者應該說在架構設計裡盡量不要使用 Link 檔案，因為這非常不利於軟體架構的設計，它看似只須要維護一次程式，事實上，它讓你每一個專案都跟這個 (*.CS/;*.VB) 程式檔案黏在一起，當你需要增加某（套件／專案）變成所有有 Link 到這個程式檔案的專案都要加，那是非常恐怖的！當我專案間需要建立相依性時，還會有循環參考的問題，最後會想拆，但是因為 Link 住了，又拆不開… 然而最好的做法是，你只要將需要將共用的部分獨立為一個 Assembly 並提供給需要用的專案參考不就都解了？這麼一來，我一樣只需要修改一次程式碼隨即套用在所有有參考的專案上面，這樣更容易的實作抽離、管理耦合性、也更好維護，不是嗎？

最後

有些 IDE 工具方便好用的功能不見得適合用在像今天這樣的情境，或者像是撰寫程式時，過分的使用語法糖對於是否真的會增加程式碼的可讀性？又或者反而增加以後維護時的困難。有時候多利用排版 + Coding Standard / Rule 、建立團隊撰寫程式碼的共識可能更加的重要。


關於 Gelis：

資深 .NET 技術顧問

FB 社團 (軟體開發之路)：

https://www.facebook.com/groups/361804473860062/

FB 粉絲團 (Gelis 的程式設計訓練營)：

https://www.facebook.com/gelis.dev.learning/

我講授過的課程 SlideShare：

https://www.slideshare.net/GelisWu


以下是我經營的項目與內容：

(1). 企業內訓課程

(2). 專業顧問


企業內訓課程：

1. .NET Core 3.1 從入門到進階

先前實體課程連結

2. 跨平台的 Web API Framework 框架設計

先前實體課程連結

3. 決戰 OOAD 系列課程 - 使用 UML

先前實體課程連結

4. 單元測試 UnitTest 與 Moq 物件實務課程

先前實體課程連結

5. 快速開發系列 - C# Project Templates 範本設計

留言

張貼留言

這個網誌中的熱門文章

軟體工程師 - 成長的 10 個階段

圖片
軟體工程師 - 成長的 10 個階段 前言 先前，我在 Study4 小聚 #6 分享的一場關於軟體工程師 & 架構設計的養成之路，在該議程中，我分享了軟體工程師的 10 個階段（你的階段如有雷同、應該是...純屬巧合。XDDD） 哪 10 個階段？ 我將軟體工程師的成長依序分為 10 個成長階段，因為隨著技能的提升，你該擴充的 不會只是只有軟體開發技術，溝通與協作能力尤其重要 ，也像是『康威定律』中所提到的， 你的軟件的設計 & 或系統設計本質上反映了企業的組織機構。系統各個模塊間的介面的設計，也反映了企業各個部門之間的信息流動和合作方式，這些技能再進行軟體架構設計時也息息相關 ，團隊在進行模組設計時需要頻繁的溝通，這些、都是是否能將軟體做好的關鍵因素。 如 Logo 圖片，我依序說明每個階段的成長歷程。 1). 初始開發階段、熟悉 Programming/Developer 階段（PM/PO/SD 給規格後加以實作出來），並能夠藉由 模仿 來學習。這是剛進入軟體產業的學習階段。 2). 此階段代表已懂得透過重構來讓程式碼有基本的可維護性 、已能熟用 DRY (Don't Repeat Yourself)，進入這個階段代表已經有基本的程式語言的基礎， 應付 Programming/Developer 日常 工作 上的需求基本上沒什麼太大的問題。 3). 這裡的專案收尾代表對於專案開發已經有某些程度的認知、掌握度。我所提的掌握度在於了解『技術債』的產生緣由 與 危害，在 Programming/Devloper 層面懂得透過 S.O.L.I.D./Design Patterns 解決問題 並 開始能夠 自我學習 + 自我成長 。 4). 我這裡用『紀錄』 代表能運用所學 + 將使用者需求運用 〔邏輯思考〕 與 〔抽象化〕 轉化為程式碼 + 並能 自我成長 將經驗保存下來。我認為這是跨越只是（寫程式／實作）進入另一個門檻的重要經驗與歷練。 這個階段花費的時間會較長一點，時間長短取決於個人歷練、經歷、學習的環境與工作內容。 5). 此階段含括上面所有技能，並能夠與〔團隊〕和〔客戶〕 溝通 與 協作 、並產生出〔產品〕。而所謂的協作代表，不只自身技術所長能應付本身開發工作工作所需，亦能帶領團隊解決軟體專案的大小事務、也能夠替...
閱讀完整內容

常見的程式碼壞味道（Code Smell or Bad Smell）

圖片
常見的程式碼壞味道（Code Smell or Bad Smell） 圖片取自：https://www.slideshare.net/ElMahdiBenzekri/art-of-refactoring-code-smells-and-microservices-antipatterns 前言 究竟重複的程式碼要不要共用它？傳統的軟體開發上，重複的程式碼幾乎被視為罪惡的來源，但是它真的有多可怕？ 常見的 Code Smells The Dispensable （一些可有可無的） Lazy Class (冗員類別） 如果一個類很少使用它會增加代碼庫的複雜性，從而阻礙開發。這樣的類可能是不必要的，它的功能可以成為另一個類的一部分。 Data Class (只有資料的類別） 一個類別只有包含『資料』未包含Methods，也就是說並未包含行為，不具行為模式的類別代表該『實例』容易被【其他類別所操控】。 Duplicate Code (重複的程式碼) 如描述，這也是上次有分享在我的 FB 社團 軟體開發之路［德國資深架構師給新手的建議］ 中有產生非常熱烈討論，這在社團朋友提醒下想起 Refactor 重構一書裡曾提過 rule of three 法則， 這個法則的定義是這樣的，有時部分程式碼重複其實是允許的（不是說重複一定是是被允許的）而是在某些 Context 情境下，該程式碼有一段時間不會衍伸別的功能 或 需求一段時間不會異動、且如要將它 DRY 會產生的『複雜度』或『花費時間』遠高於預估的時間 或 不值得在目前這個專案的節骨眼上花費這個時間來做這件事，加上它 DRY 產生的複雜度偶後產生的維護成本【遠高於】不 DRY 的情況下的維護本，那麼，在這個時候，這個異動頻率【極低】的程式碼就不需要花費這個時間來 DRY 了！！ 因為重點在於，重構是需要『成本』的。(迷之音：DRY 是種抽象化阿~😎) 這讓我想起之前，大約在 2016 年左右，在 101 的樓上某金融業客戶，曾經做過一個專案，這個專案就是因為客戶 DMZ 環境的因素，我讓內網的 Webside 與 DMZ 的網站保留了部分重複的程式碼，因為這段程式碼終年不需要異動，我也懶得花這個時間，而我居然也忘了這記件事情了.. 哈哈 Orz 不過原歸正傳，我個人還是認為，其實適當...
閱讀完整內容

什麼是 gRPC ？

圖片
圖片取自： https://grpc.io/docs/guides/ gRPC 是什麼？能吃嗎？ 在安裝了 .NET Core 3.0 之後，眼尖的朋友應該會發現，在新增 ASP.NET Core 網頁類型專案裡，會看見一個 gRPC Service 類型的專案，其實它也不是什麼很新的東西，早在十多年前 Google 就使用這樣的 RPC 協定進行一些大量的可靠性微服務的存取，聽到這，難道現有的 Web API 不可靠嗎？其實不是的，它主要用在移動設備等提供高效簡單且跨平台的通訊與熱插拔的驗證機制。 gRPC 的運作原理 gRPC 顧名思義，是種基於 RPC 的通訊協定，不同於 Web API 走的傳統 HTTP 基礎協定，它有點像是 Socket ，但應該說是基於 Socket， 或精確地來說它是基於 HTTP/2 的協定 ，gRPC 是種協議緩衝協定，它必須事先定義 IDL (Interface Definition Language) 描述檔，看到 IDL 對於一些熟悉 COM／DCOM 的朋友一定非常的熟悉，對！沒錯！就是類似的東西！但，這邊的 IDL 是用一種副檔名為 .proto 檔案來是先定義在分散式環境中，要傳輸的序列化結構資訊，當然它也可以跟 JSON 一起使用。 也就是說，要使用 gRPC 您必須先定義 .proto 協議，然後透過 Compile 的支援，編譯成特定語言框架。而很高興的是，C# 也支援了，然而其實根據官方的資料顯示，C# 應該在 .NET Core 2.1 開始就支援了，只是到了 .NET Core 3.0 才有樣版的支援。 而使用 gRPC 的協議緩衝區的服務可以做到 Stub 的機制，也就是說，它就像是許多 RPC 一樣，Client 在呼叫 Server 端時，其實是對 Stub 進行叫用，Stub 在這就像個緩衝區一般，但更細部的說，應該是一個遠程服務的替身，這應該又讓許多熟悉 COM／RPC 通訊的朋友覺得熟悉了起來，是的！沒有錯。 在 .NET Core 3.0 裡使用 gRPC 目前支援 .proto 擴展為 gRPC 協議緩衝區的編譯器只有 .NET Core 了 ， 根據 Github 上的說明 .NET Framework 4.5+ 以上或 Mono 4+ 以上也可支援，而 gRPC 也完全的跨平台。要在 ....
閱讀完整內容