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多行代码,就可以支持国产数据库或其它数据库。
它的特色有:
- 单表查询支持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, "%测试%").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", "%测试%");
- 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的问题浪费时间。
更新于:12天前