你的位置:首页 > ASP.net教程

[ASP.net教程]如何做好一个ORM框架


很多人都不太认可以第三方ORM,因为考虑的点不够全面,没有用户群体大的ORM有保证,这点是不可否认确是事实。

但是往往用户群体大的ORM又有不足之处,就拿用户群体最多的两个ORM来说一下吧

1、EF

EF性能够用,但是总体还是和轻量级ORM有一定差距,如果没有差距就没有Dapper什么事儿了。

2、Dapper

性能不错,兼容也好但是就是语法太少,基本都要手写SQL,或自已扩展,自己扩展考虑的点可能连第三方ORM都不如,只能够自已需求使用,发现问题自已来改,没发现问题也挺安逸。

 

我的ORM之旅

1、感谢大家的帮助

第一  要感谢上海蓝灯数据科技股份有限公司给我构架师一职让.NET部门都使用我的技术框架

第二  百签软件的老总的大力支持除了自已员工使用外还帮我喧传

第三  群( 225982985)里的朋友向我提了很多保贵的问题和改进的建议。

第四  chloe.ORM的作者,两个人都为了ORM基情四射

 

2、谈一谈开发SqlSugarORM框架中遇到的一些坑

而这些坑我发现博客园的一些其它ORM也普遍存在,所以我将这些问题一一的分享,也希望更多人能够指出SqlSugar的不足之处。

 

(1)、避免Sql执时计划失效

 Sql执行计划是什么,简单的说就是让Sql服务器更明确的知道你要做什么,将你的操作步骤存起来,下一次遇到同样的SQL便使用同样的操作步骤 ,大大降低SQL操作的步骤,提高性能,引起的性能差距可能是成倍的 。

参数化比拼SQL性能高的原因,也就是因为调用了系统存储过程 sp_executesql 将Sql执行计划的优势发挥了出来

如下图 name的长度为11,因为sqlparameter没有指定Size 所以nvarchar的数字是动态的,所以会导致Sql执行计划无效,一般的性能测试很难测出来,这种情况将会打乱Sql执行计划,当参数越多,参数的长度越大性能差距越明显。

而固定长度的测试根本发现不了。

 

解决方案:

将SqlParameter size<4000

全部设为4000,EF和Dapper在这点上就做的非常的棒

 

例如出现 id<1&&id>0处理两个相同的名字参数时  id<@id and id>@id+随机数   

只要加了随机数就无法进执行计划了

解决方案:

自增数 id<@id and id>@id1

 

 

2、数据类形转换成实体的处理

这一点就Dapper做的最好,EF也不错给出了很明确的错误信息。

为什么说Dapper做的最好呢,因为Dapper能把数据的int转换成实体类中的string。数据库是string转换成int时就给出了非常明确的错误信息。

目前第三方ORM都没在这方面做很好的处理

解决方案:

需要做很细的类型判段,我的做法是在Emit生成Dynamicbuilder之前处理,用数据库类型和实体类体做对比,将异常提前抛出,没有异常EMIT对象将存进缓存,预热后不会在执行。

 

 

 

3、性能的突破

就单纯拿Emit将DataReader转成List<T>来说,第三方的ORM基本上都做到了比Dapper快或者说平分秋色。

预热后一次查询100万条数据这是最好的测试方式,但要注意一点 如果走的是 DataReader的索引器 那就会有性能损耗

GetValue和索引器都是Object类型执行转换后将会产生 拆箱(将OBJECT转成了值类型),SqlSugar能在这个方面得到改进,多亏Chloe.ORM作者帮我发现了这个问题

 

4、拉姆达解析性能

如何测试自已拉姆达解析成SQL过程花时间多长呢,

测试方法:每执行一次只查询一条数据,WHERE条件多设一点。执行次数10000以上。

解决方案:在解析过程中千万不能用 Expression.Lambda(exp).Compile().DynamicInvoke(); 

用了这种写法将会带来十倍的性能之差,按上面的测试方式很容易测出性能的瓶颈。

越短的时间内执行的次数越多越容易体现出来。

 

 

发布到Nuget2周时间不到

 

 

我已经提交了这么多次修改

 

 

 

最后我只想说一句,不是第三方ORM不能用,而是你们并没有把问题指出来,代码开源就是为了让大家一起进步,一起改进。

只要作者有激情,有上进心,还担心什么呢。