Dapper.Lite 擴充套件

0611163發表於2023-11-03

最近重構並精簡了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多行程式碼,就可以支援國產資料庫或其它資料庫。

它的特色有:

  1. 單表查詢支援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寫法一樣呢?總有一個是最佳。

  1. 以SQL為主,無論何種資料庫,都是下面的寫法,這是最常用的用法
    字首有的資料庫是@符有的是:符,但ClickHouse資料庫有點不一樣,寫起來麻煩一點,這裡統一了。
    session的意思是一次資料庫會話,主要是為了資料庫事務,如果沒有事務,可以直接db.Sql
List<SysUser> list = session.Sql("select * from sys_user where id <= @Id and remark like @Remark", 20, "%測試%").ToList(); //引數按順序來,一兩個也不容易眼花

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

接著拼接:

.Append("and name like @Name", "%測試%"); 
  1. 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)

相關文章