軟體主廚的程式料理廚房

在 C# 應用程式內部要做鎖定，第一時間我們一定是先想到 lock 陳述式，但是 lock 陳述式無法在 async/await 的場景下使用，程式編譯不會通過，我們會得到一個錯誤訊息 - 無法在 lock 陳述式的主體中等候。

SQL Server 的資料型別中有一個 float，這個 float 在 C# 對應的應該是 double，而 C# 的 float 對應的 SQL Server 資料型別應該是 real，那如果將 real 對應成 C# 的 double 會發生什麼事？　答案是小數點的精準度會跑掉。

C# 從 7.0 開始加入了模式比對（Pattern Matching），最大的改變是將 switch 從常數比對中解放，讓 switch 可以比對運算式，到了 C# 8.0 更猛了，微軟弄了一個遞迴模式比對（Recursive Pattern Matching），大括號 "{}" 及小括號 "()" 寫到你不要不要的，但是模式比對裡面藏了一個 var 的陷阱，我就踩中了。

我們平常在做字串修剪的時候，一定會常用到 Trim() 方法，我們通常拿它來修剪一串字串的前後空白字元，相同的家族成員還有 TrimStart() 及 TrimEnd()，如果我們還想修剪掉其他字元，我們可以使用 Trim(Char[]) 這個多載方法，但是 Trim() 方法不是只能修剪空白字元而已。

用過 Dapper 的朋友應該對它是愛不釋手，最近在一個對效能敏感的系統上 tune SQL 查詢語句時，發現到 SQL 參數型別的不同及使不使用 SQL 參數，對執行計劃的選擇影響甚大，相同的查詢條件及結果，只因改了參數的型別，執行計劃就跟著改變，查詢成本也跟著拉高。

公司內的一個系統的開發風格轉變，Data Model 必須設計成 Immutable（不可變）的類別，其中一部分會被用在泛型上，由於 Immutable 類別是不能有無參數建構式的，所以被用在泛型的時候，它就不能用 where 進行 new() 的條件約束，沒辦法做 new() 的條件約束，就無法呼叫泛型類別的建構式來產生 Instance，著實困擾。

微軟官方部落格在去年發佈了一篇 System.IO.Pipelines: High performance IO in .NET，這個東西高不高效我是比較不出來，但是它著實解決了以往在接收 NetworkStream 時算位置的困擾，用它寫出來的程式碼簡潔清晰許多。

在 C# 中常常因為需要配合參數而動態地產生相對應的 SQL 查詢條件字串，StringBuilder 應該是公認能兼顧字串串接效能的解法，不過加號（+）還真是好用啊！相較於使用 StringBuilder，用加號來串接字串簡單又直接，因此我利用隱含轉換（implicit）來搞一個用加號串接字串，但背後其實是 StringBuilder 的解法。

TypeConverter 是從 .NET Framework 1.1 開始就有的東西，我是在 ASP.NET MVC 的 ActionFilter 中要取得某個 RouteData 時用到這個東西，它能夠幫助我們取得某個型別的轉換器，用來將另一個型別的實例轉換成該型別，這些型別或許我們在開發時間是未知的，但是在執行時期是明確的。

雖然我們大部分的服務對象是在台灣，不過我們會揭露一些國際上的資訊給使用者知曉，關於時區的問題，沒有被砸過腳還真的不會去仔細研究，尤其某些時區還會實施日光節約時間，所以千萬不要再用加減小時法來處理時區轉換的問題，有興趣的朋友可以參考我過去的文章，今天要來討論的是 DateTime 本身有沒有包含時區的資訊？