軟體主廚的程式料理廚房

Chef.DbAccess.SqlServer 這個套件是小弟本人開發的，在 ORM 工具盛行的現在，後端工程師能有一套像是 Entity Framework 的資料庫存取框架來協助開發工作，是件很幸福的事情，但是無奈因為環境的關係、政策的關係、仇恨的關係、...blah blah 的，無法盡如人意，在這種情況之下只好自立自強，於是這個套件就誕生了。

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

FOR JSON 語法是從 SQL Server 2016 開始支援，跟 FOR XML 一樣，我們可以將整筆記錄或是部分欄位輸出成 JSON 格式，輕鬆解決類別與類別之間一對一及一對多關係的情形，再搭配 Dapper 自定義 TypeHandler，讓關聯式資料庫的欄位與類別的對應轉換無聲無息。

關聯式資料庫的資料都是以表格型式呈現為主，而物件導向世界的資料型式是階層式的，面對這兩種資料呈現的型式，程式設計師在資料表的設計上著實燒腦，過去很多教授 ADO.NET 的書籍範例只會教用 DataSet、DataTable、SqlDataReader 來處理從資料庫取得的資料，如果我們直接照著用，當所面臨的需求不再如同書本範例簡單的時候，程式寫起來挺痛苦的，而我們也沒辦法享受到物件導向設計帶給我們的好處，如果我們在工作上還是需要自己下 SQL 語句，Dapper 會是我們的好幫手。

看到一段某公司對外服務的系統的程式碼，這段程式碼寫好不到一年，而這段程式碼在做一件事情，把從資料庫撈到的資料轉成物件集合，做法就是用 ADO.NET 產生 SqlDataReader，再將 SqlDataReader 丟到一個靜態方法，在靜態方法裡面逐筆讀取資料，接著透過 Reflection 動態地產生物件集合，但是物件的 Property Name 就遷就 ColumnName，一整個怪啊！

如果我們要練習 Reflection 的用法，這是個非常好的練習，但是要用在 Production 上我們還有 Dapper 可以選擇，搭配我接下來要介紹的三種自定義欄位對應方式，我相信怎樣都比自己寫 Reflection 來得好。