Simple Is Not Easy

在開發的過程, 常常有一些需要改進但現階段沒時間做的部分, 我們在上面加上一個 // TODO: 的註解來標註, 甚至依照特性的不同會用不一樣的語彙(Token)來標註, 例如: // BadSmell: 等等, Visual Studio 已經有內建幾個常用語彙, 除了這些內建語彙外我們也可以自己新增團隊內部使用的語彙.

另一方面, 這些工作清單慢慢累積後就會變得不好管理, 這部分也可以通過 Visual Studio 提供的相關功能來協助我們管理.

很多 .NET 開發人員對於 StyleCop 應該是不陌生, 它能有效地協助我們讓程式碼的風格保持一致, 預設的規則其實已經足夠了, 但有些團隊可能有自已的特殊編碼規範, 這些編碼規範甚至是跟預設的規則是衝突的, 這時候就需要自己寫規則來套用.

這篇主要是針對自訂規則可能會面臨的問題所記錄的, 尤其是要怎麼測試這些規則沒寫錯, 所以對於一些 google 就可以很容易找到的部分只會簡單帶過, 另外由於 StyleCop 也滿大的, 所以有些太細的設定或是內部運作這篇也不打算深入探索, 等之後有需要或是有興趣再根據各個主題或面向來專題探討.

XmlSerializer 提供許多序列化和反序列化相關的多載, 都有各自的優缺點, 例如有些方式在某些編碼下會因為 BOM(byte order mark) 出現在開頭而導致反序列化出現 Exception 或是序列化出含有 BOM 的字串導致接收端無法成功解析, 而各種方式的彈性與易用性都略有不同, 所以稍微記錄幾種序列化和反序列化的方式與特徵.

標題下的有點奇怪, 框架預設提供 Model Binding 來將請求內容(request body)綁定到參數中, 其實一般情境不需要手工去讀取它的. 但是之前遇到一個情境是需要在 ActionFilterAttribute 中取得請求內容並紀錄到日誌 (log) 中, 這時候問題就來了.

最近在寫一個比較方便使用的工具方法來做 XML 的序列化的時候, 發生了一個神奇的問題, XmlWriterSettings.Encoding 預設應該是 UTF-8, 但是轉出來的 XML 卻是 UTF-16, 這就奇了怪了…

ASP.NET WebApi 2 提供了三個好用的 FilterAttribute 讓開發者可以擴充後將這些 FilterAttribute 套用在 Controller / Action 上面, 也可以在 WebApiConfig.cs 或 Global.asax 裡面註冊 , 並在一個 API request 生命週期中的特定時間被執行.
這樣做的好處是可以將跟 API 主業務邏輯無關, 卻又是大部分 API 都要做的事收斂起來, 只需要將 Attribute 套用在正確的地方就能一體適用, 開發者就能更專注在 API 的主要商務邏輯層面.

在了解 FilterAttribute 的運用之前, 必須先知道 Attribute 是什麼以及如何使用 Attribute.

遞迴有一個很大的好處是能用非常簡短的程式碼達到相對複雜很多的功能, 一般來說可讀性高很多, 但也伴隨著一些問題, 例如不慎引發堆疊溢位(stack overflow), 這篇主要是要紀錄怎麼安全的使用遞迴.

自動實作屬性(auto implemented properties)是 C# 非常基本的規格, 雖然他跟 欄位(fileds) 使用上非常相似, 但本質上是不一樣的東西.
這篇主要是紀錄一些網路上的比較資訊以及自己好奇下做的一個小實驗, 沒什麼太特別的內容.

if 條件式很常用, 但在有時因為使用不當造成閱讀或維護上的困難, 尤其是巢狀的 if-else 條件式對維護上造成很大的負擔, 這其實是有一些小技巧可以簡化 if 條件式的, 當然, 這些技巧不是萬靈丹, 使用上還是有些細節要注意的.

責任鏈模式在教科書上的典型範例是用在簽核流程上, 也就是一個任務/資料會依序流過各個處理節點, 每個節點會判斷任務/資料是不是在自己的權責範圍內, 決定要自己處理還是繼續往下拋.

前陣子公司專案剛好有一個類似情境, 但需求與教科書用法不同, 第一時間想到一個變形的作法, 而公司大神也提供了另一個更簡潔的做法, 趁還沒忘整理一下記下來.

完整的示範專案和文件