可能只有我不知道,但是不記下來又覺得需要解釋的時候會解釋不出來。
責任鏈模式 - Fluent 風格
一般範例中的責任鏈,負責組合各實作的 Handler 時通常會如下方這樣組合,這樣的做法不管從操作上還是閱讀上都比較不友善:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16// Init
IHandler positiveEven = new PositiveEvenHandler();
IHandler negativeEven = new NegativeEvenHandler();
IHandler positiveOdd = new PositiveOddHandler();
IHandler negativeOdd = new NegativeOddHandler();
// Configure
positiveEven.SetNext(negativeEven);
negativeEven.SetNext(positiveOdd);
positiveOdd.SetNext(negativeOdd);
// Call the chain
positiveEven.Handle(1);
positiveEven.Handle(-1);
positiveEven.Handle(2);
positiveEven.Handle(-2);
這篇主要是紀錄透過簡單的修改讓 Handler 能更簡單的組合責任鏈。
C# 語言特性更新 - C# 7
C# 各版本新特性摘要,包含自己的想法與實務上的偏好。
C# 7 系列比較特殊,總共經過 7.0、7.1、7.2、7.3 四個版本,且範圍有高度重疊,所以這邊不分開看,直接依照 2021 年版官方整合過的文件將 C# 7 的新特性一起看。
可重用的 XML 文件註解
在 EF Core 中自定義 ValueConverter
關於 EF Core 中的值轉換 (Value Conversion),官方文件已經展示的非常詳細,但這樣的實作使得值轉換和 DbContext
高度相依,在中小型專案中這樣已經足夠,但在複雜的產品群中,如果需要基於 EF Core 建立內部共用的套件,就會難以將這些客製化的 ValueConverter
從套件中抽離,也難以讓應用程式自行擴充自己特殊的 ValueConverter
,本文主要提供另外一個面向的實作來達到更低的耦合度與更高的可擴充性。
在 Switch-Case 中使用重名區域變數與延伸探討
問題起始於一個情境如下:1
2
3
4
5
6
7
8
9
10
11
12
13
14switch (cryptoType)
{
case CryptoType.AesEncrypt:
var key = "";
var iv = "";
break;
case CryptoType.AesDecrypt:
var key = "";
var iv = "";
break;
// Others
default:
break;
}
這時候因為 case 之間的區域變數名字重複了所以編譯不會通過。
現實情境更複雜,
CryptoType
可能有幾十個。這邊要先聲明,理論上這種大量的 switch-case 有很多設計可以管理它,但實務上是一個老舊又缺乏架構的專案,甚至亂到重構後的檔案放哪都只會更亂的程度,而如果只是抽出方法,那一些簡單的情境就會因此被抽出大量小型方法,且都放在同一個類別中也不會比較好。
總之,這個例子只是拿來說明區域變數與其作用域和生命週期,不表示例子中的設計是恰當的。
設計 WebAPI 通用回傳模板
在我以往的工作經驗中,處理過不少 WebAPI 的維護工作,普遍面臨的一個問題是回傳資料的不一致性。舉例來說,常見的幾種回傳格式包括:
- 純值:
true
、100
等,會出現在回傳單一值的 API 中。 - 物件:
{"name": "Ron", "gender": "Male"}
,會出現在回傳物件的 API 中。 - 物件含狀態:
{"status": "1001", "name": "Ron", "gender": "Male"}
,會出現在呼叫端需要知道更多狀態細節時。 - 其他變種:除了資料外還有各種狀態、錯誤、訊息等欄位,但格式與名稱不統一。
這個現象造成的問題就是明明是同一個站台對外提供服務,回傳的狀態訊息卻每個 API 都不一樣,不僅對使用者不友善,也會讓接手維護的人無所適從。
本篇文章會介紹並分析的幾種解決方案,所有方案都有高一致性與關注點分離的共同優點,但也有些不同的缺點。
客製 .NET 程式碼分析與自動修正
.NET 編譯器平台 (Roslyn) 分析器 提供很多有用的程式碼分析規則讓我們更容易維持良好的程式碼品質,但有時候我們會需要自己定義一些規則來符合專案開發規範。官方以及其他網路文章其實已經提供了不少資訊,但因為步驟和說明真的很多,了解起來太花時間,於是想自己來整理一下讓需要的人可以快速走完所有步驟。
樂觀鎖與悲觀鎖的選擇
在資料庫操作時,面對多個操作的並行操作,為了避免資料不一致和衝突我們主要有兩種方法可以達成這個目標:樂觀鎖 (Optimistic Lock) 和悲觀鎖 (Pessimistic Lock)。但我們應該如何選擇適合的方法呢?
樂觀鎖和悲觀鎖的實作網路資源太多了,這篇不會特別提。