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支持。
C# 复制代码
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
C# 复制代码
List<SysUser> list = session.Sql("select * from sys_user where id <= @Id and remark like @Remark", 20, "%测试%"); //参数按顺序来,一两个也不容易眼花

C# 复制代码
List<SysUser> list = session.Sql("select * from sys_user where id <= @Id and remark like @Remark", new { Id = 20, Remark = "%345%" }); //参数多的话就这么写吧

接着拼接:

C# 复制代码
.Append("and name like @Name", "%测试%"); 
  1. SQL拼接查询条件支持Lambda表达式
    既然写SQL了,那也无法使用强类型了,表名改了SQL要改。Where条件这样写比SQL方便一点点。有的orm在字符串中使用{nameof(xxx)},但有点丑,写起来也费事,字符串里都是大括号不好阅读。
C# 复制代码
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)

相关推荐
沛沛老爹11 天前
Python Django全功能框架开发秘籍
python·django·orm·web开发·模板引擎·项目部署·表单处理
掉头发的王富贵16 天前
【JOOQ】同事凭什么说它是世界上最好用的ORM框架
后端·mybatis·orm
o0向阳而生0o20 天前
68、.NET Entity Framework(EF)
.net·orm·ef
xiangji24 天前
.net 实现 CQRS 的的一个设想
orm·sqlbuilder
却尘1 个月前
当全世界都在用 Rust 重写一切时,Prisma 却选择了反方向
前端·数据库·orm
喵个咪1 个月前
开箱即用的GO后台管理系统 Kratos Admin - 代码生成工具集
微服务·orm·protobuf
xiangji1 个月前
ShadowSql.net之正确使用方式
orm·dapper·可扩展·sqlbuilder·面向接口
MyikJ1 个月前
Java求职面试:从Spring到微服务的技术挑战
java·数据库·spring boot·spring cloud·微服务·orm·面试技巧
Jaising6661 个月前
Mybatis Plus 多租户实现思路分析
spring boot·mybatis·orm
xiangji1 个月前
ShadowSql之表达式树
orm·sqlbuilder