看到一段某公司對外服務的系統的程式碼，這段程式碼寫好不到一年，而這段程式碼在做一件事情，把從資料庫撈到的資料轉成物件集合，做法就是用 ADO.NET 產生 SqlDataReader，再將 SqlDataReader 丟到一個靜態方法，在靜態方法裡面逐筆讀取資料，接著透過 Reflection 動態地產生物件集合，但是物件的 Property Name 就遷就 ColumnName，一整個怪啊！
如果我們要練習 Reflection 的用法，這是個非常好的練習，但是要用在 Production 上我們還有 Dapper 可以選擇，搭配我接下來要介紹的三種自定義欄位對應方式，我相信怎樣都比自己寫 Reflection 來得好。
我在之前的專案有使用過 ASP.NET Identity 來幫我做驗證的工作，ASP.NET Identity 的出現為驗證身份的方式帶來了更大的彈性，不過如何使用不是這道菜的重點，這道料理要展現的是，當我們為 Controller Action 做有身份識別的單元測試時，我們要如何偽造不同的身份來滿足測試情境？
使用 Entity Framework 大都會搭配 Lambda Expression 到資料庫去 Query 資料出來，但是通常我們只能在程式碼中先寫好查詢的條件，當遇到不同條件的時候就要再寫一組查詢的條件，那我們能不能寫一個查詢條件的產生器，可以依照我丟進去的條件參數，幫我產生不同組合的查詢條件？
在有繼承關係的類別中使用 AutoMapper 為整個繼承鏈的類別做 OOM 有很多眉角需要注意，包含使用 Include 語法宣告所有派生類別的對應，以及為所有派生類別明確地建立對應地圖，就在前幾天我踩到了 Ignore() 的地雷...
軟體廚房開始推出小菜一碟系列，這系列的篇幅不長，但是裡面都會有一言以蔽之的重點，像這篇就是在講我們自訂了一個 ModelBinder，它要怎麼做單元測試？
我們拿[料理佳餚] ASP.NET MVC 自訂 ModelBinder 將宣告為抽象型別的參數反序列化這篇的例子來看一下。
如果我們是真的用物件導向在設計程式，那麼一定會用到抽象類的型別（Abstract Class、Interface），在現今當下的資料交換格式中，JSON 算是大家首選的格式，可是當我們的設計相依於抽象之後，序列化及反序列化就變成一個我們必須特別要處理的點，序列化倒是還好，反序列化就比較頭痛了。
實行敏捷開發的團隊大部分都會用 User Story 來梳理使用者的需求，依照團隊的情況，每個團隊實行的方式也不盡相同，看起來差不多，可是細節卻有差。
User Story 看似簡單，操作起來卻有很多地方需要注意，一不小心很容易成為災難一場，不僅徒勞無功，又累死三軍，下面記錄我最近一次使用 User Story 的經驗，過程多少有一些操作得不是很好的地方，把它寫下來後，希望可以做為我未來調整及修正的方向。
在第一式 [料理佳餚] 十三太保橫練 Windows 跨足 CentOS - 第一式我們提到了 Linux 的主要發行版本及選擇、目錄結構和常用的主要目錄、作業系統安裝及要注意的步驟，緊接著我們要克服的是 Windows 跨足到 Linux 必須要面對的問題之一 -「可能沒有 GUI」，話說得保守是因為現在 Linux 的世界還是積極地在發展 GUI，但是現今仍是 Command Line 的天下，看到要下指令有些人頭就大了，請不要擔心，我們會用到的指令其實不多。
我們要解決問題只靠單一的技能會讓解決方案受到限制，Windows Server 友善的 GUI 畫面實在讓人愛不釋手，但偏偏一些好用的開源工具及服務，在 Windows Server 上的支援及資源是比較少的，當我在看到這篇文章 ASP.NET Core – 2300% More Requests Served Per Second 之後想一想，其實花點時間把 Linux 購入工具包有益無害。
看了董大偉老師的文章「關於LineBot (1) - 用c#建立一個LineBot」之後，我也來跟風一下，可是只有簡單的機器人回應有一點單調，憑藉著我以前在 CTI 領域的經驗，來實作一個簡易型的 IM 客服進線功能。
Developer Technologies (2016-2023)