之前寫的DBHelper，名稱確實太Low，就改了個名，叫LiteSql，本來想叫SqlShuttle(SQL一把梭)，奈何單詞太長。 有兩個版本，一個是LiteSql，一個是Dapper.LiteSql，LiteSql底層用的是ADO.NET，Dapper.LiteSql底層用的是Dapper，提 ...
之前寫的DBHelper，名稱確實太Low，就改了個名，叫LiteSql，本來想叫SqlShuttle(SQL一把梭)，奈何單詞太長。
有兩個版本，一個是LiteSql，一個是Dapper.LiteSql，LiteSql底層用的是ADO.NET，Dapper.LiteSql底層用的是Dapper，提供的介面和功能是一樣的。
Dapper.LiteSql算是Dapper擴展。
簡介
一款使用原生SQL查詢的輕量級ORM，支持Oracle、MSSQL、MySQL、PostgreSQL、SQLite、Access資料庫。
代碼來源
代碼來源於需求，我整個職業生涯待過的公司，要麼用NHibernate要麼用DBHelper，NHibernate我很討厭，所以就折騰DBHelper了。原始版本的四個主流資料庫的DBHelper，都是經歷過實際項目的，不過現在除了自己寫程式或小項目，我自己沒有機會用了，沒有需求就沒有新功能，最近也只加了個手動分表的支持。
文檔
https://gitee.com/s0611163/LiteSql/blob/main/README.md
https://gitee.com/s0611163/Dapper.LiteSql/blob/main/README.md
NuGet
https://www.nuget.org/packages/LiteSql
https://www.nuget.org/packages/Dapper.LiteSql
為什麼用LiteSql
並非推薦大家用，但我相信會有人需要的，所以有必要寫這個博客自薦一下。
EF和EFCore雖然我寫過Demo，但我只能說我不瞭解。FreeSql和SqlSugar是語法糖的代表，功能很多很強大，語法糖最重要的是要儘量符合使用習慣，使大家儘量不看文檔，就能猜出來怎麼用，在這方面FreeSql和SqlSugar很難超越，所以沒必要重覆造輪子，除非有人覺得可以超越。SmartSQL類似Java的MyBatis。Dos.ORM我也看了一下，好像跟上述兩款同一類型。
Dapper不帶擴展肯定不好用，要是100多個欄位的表能寫死人。Dapper.Contrib遇到資料庫欄位名和屬性名不一致的情況還得自己想辦法，DapperExtensions要寫Mapping，那就是在用了擴展的情況下，自己再寫個小擴展。有人寫Demo就不考慮100多個欄位的情況，我知道你可能有自動生成的工具，你不說，就是沒有。
後續的話，對標FreeSql、SqlSugar那是不可能了，理念不同。能成為DBHelper的終級版或者Dapper擴展的終極版就很好了，這是需要首先進行科學論證的，我想EFCore肯定是經過科學論證的，這裡的科學家是指微軟的頂級大牛們。你說Dapper.Contrib有15M的下載量，怎麼就不解決一下欄位名和屬性名不一致的情況，是什麼理念導致的？DapperExtensions要寫Mapping，減少對實體類的侵入性，肯定是一種理念，但100個欄位我該怎麼寫，用什麼方案？
對於這個ORM，現在的問題是，我沒有用C#寫增刪改查的機會了，所以我不知道有什麼需要改進的地方，空想是想不出來的。我是希望有人共同維護，但一定要有理念和邊界，不是什麼功能都可以加，不然的話為什麼Dapper功能那麼少？
怎麼用？
怎麼用請看文檔。這裡我只說一點。
在我上家公司用OracleHelper或SqlServerHelper的時候，查詢、分頁查詢是一種固定寫法，適應性廣，我覺得很好，代碼結構非常清晰，很容易看懂和維護。
