Dapper.Lite 擴充套件 - tw511教學網

最近重構並精簡了Dapper.Lite，然後把不依賴Dapper的版本LiteSql也重構了一下，和Dapper.Lite保持一致。感覺這兩款ORM基本完工，自薦一下。

.NET的ORM雖多，堪用的不多，何為堪用，EF是官方的，質量高，堪用。Dapper使用者量大，現在BUG基本改的差不多了，也基本不增加新功能，就不會引入新BUG。SqlSugar和FreeSql有一定的使用者量，發現BUG修復BUG，也算堪用。其它的，就只能自己用了(除EF、Dapper之外國外的，也有不錯的，似乎國內用的少)。

大家做的專案有沒有上限？做三流專案還是一流專案？做三流專案的話，什麼ORM都可以試一試的。做一流專案，EF不會影響專案的上限，Dapper也不會影響專案的上限，ADO.NET也不會影響專案的上限只是寫起來費事了。SqlSugar和FreeSql會不會影響專案的上限？用國產ORM做的專案能否和Java專案拼一拼？MyBatis雖然又臭又長，但肯定翻不了車，也不會影響專案的上限。

何為專案的上限？極限效能？穩定可靠？我就想狂懟mysql的時候，幾個月不寫一條error紀錄檔。放在伺服器上的服務，上次error是10月2日的和資料庫操作無關，上上次error是9月18日的，就一條error原因已知。

寫了一款Dapper.Lite，自己用，並分享給大家。使用者很重要，最近幾個月僅一個加群找我的使用者，就幫我修復了一個bug，並提了一條功能上的建議。所以，使用者量少，也可以說限制了Dapper.Lite的上限。

Dapper.Lite是一款Dapper擴充套件，單表查詢和SQL拼接查詢條件支援Lambda表示式，旨在為大家提供一款簡單易用、穩定可靠的ORM，支援Oracle、MSSQL、MySQL、PostgreSQL、SQLite、Access、ClickHouse等資料庫。照著抄一份Provider改改，寫100多行程式碼，就可以支援國產資料庫或其它資料庫。

它的特色有：

單表查詢支援Lambda
就一個單表查詢還寫SQL有點麻煩，我也不想寫，所以做了Lambda支援。

List<SysUser> list = session.Queryable<SysUser>().Where(t => t.Id <= 20 && t.Remark.Contains("測試")).ToList();

這次重構，連表查詢、子查詢等複雜功能都刪除了。你可以去看看SqlSugar和FreeSql等的原始碼，每個資料庫的實現細節是不一樣的，很複雜。複雜可能會引入bug，增加新功能可能會引入bug，就算沒有bug，你不會用，看檔案不仔細，也可能會寫出bug，船大難掉頭，打修補程式可能會帶來妥協的語法，CopyNew就是這麼來的，不然FreeSql的Lambda為什麼不跟SqlSugar寫法一樣呢？總有一個是最佳。

以SQL為主，無論何種資料庫，都是下面的寫法，這是最常用的用法
字首有的資料庫是@符有的是:符，但ClickHouse資料庫有點不一樣，寫起來麻煩一點，這裡統一了。
session的意思是一次資料庫對談，主要是為了資料庫事務，如果沒有事務，可以直接db.Sql

List<SysUser> list = session.Sql("select * from sys_user where id <= @Id and remark like @Remark", 20, "%測試%"); //引數按順序來，一兩個也不容易眼花

或

List<SysUser> list = session.Sql("select * from sys_user where id <= @Id and remark like @Remark", new { Id = 20, Remark = "%345%" }); //引數多的話就這麼寫吧

接著拼接：

.Append("and name like @Name", "%測試%");

SQL拼接查詢條件支援Lambda表示式
既然寫SQL了，那也無法使用強型別了，表名改了SQL要改。Where條件這樣寫比SQL方便一點點。有的orm在字串中使用{nameof(xxx)}，但有點醜，寫起來也費事，字串裡都是大括號不好閱讀。

List<KpTask> kpTaskList = await session
    .Sql<KpTask>(@"
      select t.*, m.model_start as ModelStart, m.model_end as ModelEnd
      from kp_task t
      left join kp_model m on m.model_id=t.model_id")
    .Where(t => t.IsDel == 0)
    .Where(t => new int?[] { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 }.Contains(t.OpeType))
    .Where<KpModel>(m => m.ModelStart <= DateTime.Now && DateTime.Now <= m.ModelEnd)
    .ToListAsync();

Dapper.Lite有沒有BUG？有沒有設計缺陷？可能會有，但暫時不知道，目前主要是我自己用，我的使用場景不夠豐富。5000多行程式碼，掃一眼就能發現有沒有問題。

大道至簡，Dapper.Lite的目標是簡單易用，穩定可靠。

Dapper沒有擴充套件並不方便，支援Lambda表示式的擴充套件，有SqlSugar方便嗎？沒有！能保證沒有BUG嗎，還在維護嗎？BUG誰修？不支援Lambda表示式的擴充套件，也不方便。如今似乎Dapper相關的部落格少，可能用的人也少。只要Java的MyBatis還活著，.net就不能只有EF、SqlSugar這類選項。Dapper相當於Java的JdbcTemplate，有的專案就是直接用的JdbcTemplate。

正經專案能用EF當然是EF，但如果你對EF有遲疑，對SqlSugar也猶豫，或者你喜歡寫SQL，打算用Dapper，不妨試試Dapper.Lite，直接NuGet下載安裝，如果有問題，至少Dapper.Lite的原始碼是你能hold住的。

有使用者沒有使用Dapper.Lite而使用了LiteSql操作Access，說是Dapper操作Access也有點問題，原因他也忘了。所以最近LiteSql也重構更新了一下，和Dapper.Lite介面是一樣的。

如果Dapper.Lite使用者數量多一些的時候，如果沒有出現難以修復的致命問題，如果不需要再重構，如果介面沒什麼變化，也不用增加什麼新介面，它就達到了我認為的優秀，它的目標不是功能強大，它的目標是我做專案的時候，不想因為orm的問題浪費時間。

(主要是自己做下宣傳，增加一點使用者，有助於改進和質量，不想又因為ORM引起爭論，也非同類ORM，多一種選擇。如今寫orm的話題顯得比較low，不過你們寫的技術，很多我都用不到，但不管什麼專案，幾乎都要用到orm)