最近改造我之前写的DBHelper总结

  • 最近改造我之前写的DBHelper总结已关闭评论
  • 11 次浏览
  • A+
所属分类:.NET技术
摘要

又是写ORM的博客,但是写其它的类库,我不会啊,只有这个我能写一写,希望大家轻喷

又是写ORM的博客,但是写其它的类库,我不会啊,只有这个我能写一写,希望大家轻喷

最近修改内容

以前只支持.NET Framework,现在修改为支持.NET Framework、.NET Standard、.NET Core多目标平台  以前工程依赖了具体的数据库操作类库,不方便实现支持多目标平台,为此,修改了架构,把Provider移到了工程外  这样改造之后,竟然可以支持任意关系数据库,需要编写的Provider,需要实现的功能很少,除了创建分页SQL,就没什么了,lambda可以不支持。  写完之后进行性能测试,对比EF、Dapper、FreeSql、SqlSugar,发现循环更新和查询,性能比较差,为此,我看了Dapper、FreeSql、SqlSugar,实体类赋值相关的源码,发现SqlSugar用的是Emit,Dapper用的是Emit和表达式树,而FreeSql用的是表达式树,而我用的是反射,性能自然差一些,不过反射赋值代码很简单。经过学习,我用Emit实现了相同的性能,但做更多测试的时候,发现了BUG,于是我去看它们的源码,发现代码量都不小,FreeSql的表达式树,居然有2000多行代码,SqlSugar也不简单,麻烦的主要是数据类型处理,居然还为SQLite做了单独处理。于是我放弃了,使用反射,性能也只能这样了。  突然想到,我可以把底层用的ADO.NET换成Dapper,一来性能好,二来大家更信任Dapper,这样的话,这个DBHelper实际做的工作就更少了,插入、更新则是把实体类翻译成SQL交给Dapper执行,查询则是把SQL直接交给Dapper执行,当然,分页查询Dapper本身是没有的,我想可能是因为分页SQL,不同的数据库写法差异很大,所以Dapper把它交给扩展去做了。看到NuGet上众多的Dapper扩展,我突然感觉,Dapper其实不是一个ORM,它是一个基础设施,就像JdbcTemplate一样。  说干就干,也就花了一天,把底层换成了Dapper,查询性能和FreeSql、SqlSugar一样了,分页查询慢一点,因为我在分页查询里,查了总数,看来这个方法后面需要再优化一下,可是更新还是慢,因为我在更新里,又查了一次数据,然后比对,只更新变化的字段。继续优化,参照FreeSql的Attach,实现了一个AttachOld方法,用到AutoMapper以保证性能,用于把更新前的旧数据存一下,这样修改之后,更新的性能也和FreeSql、SqlSugar一样了,至此,性能问题算是基本解决了。 

收获

  1. 学会了NuGet打包发布

    最近一共发了4个NuGet包
    https://www.nuget.org/profiles/s0611163

  2. 学会了如何开发支持多目标平台的库

感想

平时工作渐渐以Java为主了,工作中写C#的机会越来越少。Java开源项目太多,加上自己初学,也没有水平写类库,写Java自己只是个调包侠,开源框架源码也看不懂。通过写C#、看C#的开源项目源码,可以练练技术。工作多年,以前从未看过别人写的源码,最近,因为想写好自己的类库,所以看了一点NLog、以及各ORM的源码,学了一点东西。还是很喜欢.NET的,最近把自己写的LogUtil放到Linux系统下跑了跑,算是初步学会了如何把.NET程序跑在Linux系统上。  我看好.NET,期待.NET 8,但愿以后有机会在工作中使用。 

NuGet地址

  1. 非Dapper版

    可以支持更多的数据库,Provider需要自己写,不过代码量很小
    https://www.nuget.org/packages/sux.DBHelper

  2. Dapper版

    .NET Framework 4.6.1及以上
    https://www.nuget.org/packages/Dapper.DBHelper

源码地址

  1. Gitee地址

    https://gitee.com/s0611163/DBHelper

  2. GitHub地址

    https://github.com/0611163/DBHelper

  3. .NET5 .NET6测试源码

    https://gitee.com/s0611163/DBHelperCore/tree/dbhelper-test/