Dapper.Lite 扩展

最近重构并精简了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, "%测试%"); //参数按顺序来，一两个也不容易眼花

或

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", "%测试%");

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)