程序猿求生指南

短小精悍的.NET ORM神器 -- Dapper 應該有很多人像我一樣，對LINQ的依賴已經到達 "LINQ or  Die!"(不LINQ，吾寧死) 的地步，到了需要存取DB的場合，打死也不想再走ADO.NET + DataTable、DataRow的回頭路。不過，在專案引用EntityFramework或其他ORM解決方案(NHibernation、SubSonic...)，固然嚴謹紮實，卻也多出額外工作--要依照Schema在專案定義Entity物件、資料庫變更時要記得同步更新Entity定義，遇到多TABLE JOIN查詢得另外宣告自訂類別承接查詢結果(我還為此寫過 潛盾機 )。對於要求嚴謹精準的中大型系統，這類準備工作屬無法避免的代價，但在一些力求快速輕巧的開發情境(例如: 轉檔工具、範例程式、單純但大量的報表需求...)，所有對資料庫的存取(Table、View、Stored Procedure)需預先定義，還必須隨時保持與資料庫一致，引用EF之類的架構便顯笨重。 前陣子提到 用TVP傳WHERE IN參數 的做法，在 FB專頁 得到網友Lane Kuo的回饋(在此致謝)，得知好物一枚 --  Dapper (英文原義是短小精悍，用過即知Dapper不負其名)，一個精簡小巧的.NET ORM工具，不需在專案裡新增DB Table、View或Stored Procuedure定義，只要取得IDbConnection(SqlConnection、OracleConnection、MySqlConnection...都適用)，就能立即享受接近EF、LINQ to SQL等ORM架構的便利，最重要的是能用LINQ把玩資料，這才是上流社會的程式寫法呀! 不囉嗦，打開NuGet就能找到它: 試用之後，感動到直起雞皮疙瘩，這就是我一直在尋找的，好吃又不黏牙的DB LINQ解決方案~ 以下整理Dapper的特色: 第一點絕對要大推! 之前在公司推廣LINQ/EF，最常被挑戰的罩門 -- "過去不管再複雜的SELECT FROM WHERE，丟給ADO.NET就能拿到DataTable；弄了LINQ/EF之後，不定義Entity或自訂類別就收不到結果。幹! 你知道我的系統裡有多少個花式SELECT嗎?...

This post looks at writing a repository implementation using the Micro-ORM named  Dapper . This post is part of a blog series  ASP.Net 10 Years On . Even though this is part of a series I have tried to make each post standalone. Update I've improved upon this implementation. See  this post  for details. Original In the  previous post  we compared options for our repository implementation and we concluded that a Micro-ORM was best suited for our requirements. We decided on  Dapper  as our tool. To recap, we chose a Micro-ORM as we wanted to balance automation and control over SQL queries in the application. We're happy for the nontrivial stuff to be automated but we want control over any SQL that has a JOIN or more. To kick off our repository we start with a base repository interface. All domain level repository interfaces will implement this interface as it will offer the convention we seek in making all repositories uniform: public ...