看到 Bill 叔在 twMVC#39 講的 Compile-time weaving 的 AOP 框架 - PostSharp，勾起了我的 AOP 魂，隨手 Google 了一下，讓我找到了一個 Open Source 的框架 - AspectInjector（看名字我還以為是某個 Dependency Injection 的套件），看它在 GitHub 的介紹裡面下了 postsharp 的標籤，似乎有向 PostSharp 看齊的目標。
在 C# 講到 Object-Object Mapping，AutoMapper 絕對是在解決方案清單的前幾名，也是我推薦的首選，不過如果我們只是偶爾在程式的某個小角落，需要把一個類別對應成另一個類別，這時候我們可能不會想要去安裝 AutoMapper、寫 Mapping Configuration，會想說是不是有一個更輕量的方法來解決我們當前的問題？
在 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 時算位置的困擾，用它寫出來的程式碼簡潔清晰許多。
