最近重構並精簡了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)