之前写的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的时候，查询、分页查询是一种固定写法，适应性广，我觉得很好，代码结构非常清晰，很容易看懂和维护。