.net下开源轻量级ORM框架Dapper扩展系列4（重构与优化）

经过前面三个系列的扩展，功能已经全部实现。不过也暴露了很多不足，主要体现在代码混乱有些地方重复处理，更重要的是性能比较差。

今天就从这两方面下手，尽可能的解决这些问题。

 

代码优化

 

主要内容如下：

1.取消了扩展中把事务封装在里面

原因：如果封装在扩展里面，事务处理将失去灵活性。

2.将SQL组装全部转移至SqlQuery类中，从而代码更清晰：

 

 View Code

3.扩展类只有简单调用，再无复杂逻辑DapperEx：

 

 View Code

更多细节请看文章最后送上的源码。

性能优化

 

在前三个系列中的扩展，不知道有没有人去测试性能，反正我是测试了一下，结果就不放出来了，反正我只想说性能“很差”，特别是反复查询时，性能差到极点。

主要内容如下：

1.添加了一个实体描述类，用于保存反射后的实体(ModelDes):

 

 View Code

2.添加了一个静态缓存，用于保存已经反射过的实体，用于再次使用时，直接从缓存中取出：

 

 /// <summary>

        /// 用于缓存对象转换实体

        /// </summary>

        private static Dictionary<string, ModelDes> _ModelDesCache = new Dictionary<string, ModelDes>();

缓存操作主要方法如下：

 

 View Code

改到比较大，以前的Common类基本上是重写代码。

 

3.SqlQuery中生成有一个极耗性能的，就是动态生成参数类，此处也加入了缓存，（加入后简直一个在天上一个在地上的区别）。

 

 //动态参数类缓存

        protected static Dictionary<string, Type> DynamicParamModelCache = new Dictionary<string, Type>();

具体处理代码：

 

 View Code

由于前面代码优化中，我把参数进行了特殊的处理，这里通过表名和参数名组合成一个缓存的KEY，匹配KEY时，只要现在请求的参数集合与已经存在KEY转换在参数集合进行对比，

 

只要是已经存在KEY的子集，就说明缓存存在。例：

缓存中存在一个缓存，其key:“account_Id1_CreateTime1_CreateTime2”,一个新的SQL执行时，组合的key为：“account_Id1_CreateTime1”，那么后面这个KEY就是前面这个KEY的子集，就用已经存在key:“account_Id1_CreateTime1_CreateTime2”的缓存做为参数对象。

 

其它更多处理也请看源码。

 

性能测试

下面我们对优化后的扩展和原生Dapper进行性能对比，看看性能相差会不会很大

以下是通过500次循环，每一次循环都进行100次重复查询或者添加删除操作，以下是5次对比结果：

 

 

 

 

 

 

通过以上性能对比

扩展性能比原生Dapper从性能上说，每一100次插入和删除数据，相差3-4毫秒，查询相差要“大一点点”，7-8毫秒如果 

进而平均到每一次的操作上的话，相差只有0.0几毫秒。

通过性能对比，操作耗时已经很低了，完全在可接受范围内。在此我们的dapper扩展系列告一段落，谢谢大家的。

说明：程序中如存在错误与不合理请指正，在此谢谢！