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

最近改造我之前写的DBHelper总结已关闭评论
176 次浏览

A+

所属分类：.NET技术

摘要

又是写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一样了，至此，性能问题算是基本解决了。

收获

学会了NuGet打包发布

最近一共发了4个NuGet包
https://www.nuget.org/profiles/s0611163
学会了如何开发支持多目标平台的库

感想

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

NuGet地址

非Dapper版

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

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