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

　　经过前面三个系列的扩展，功能已经全部实现。不过也了很多不足，主要体现在代码混乱有些地方重复处理，更重要的是性能比较差。 今天就从这两方面下手，尽可能的解决这些问题。 代码优化 主要内容如下： 1.取消了扩展中把事务封装在里面 原因：如果封装在

　　经过前面三个系列的扩展，功能已经全部实现。不过也了很多不足，主要体现在代码混乱有些地方重复处理，更重要的是性能比较差。今天就从这两方面下手，尽可能的解决这些问题。

　　代码优化

　　主要内容如下：

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

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

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

　　View Code

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

　　View Code

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

　　性能优化

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

　　主要内容如下：

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

　　View Code

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

　　/// summary

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

　　/// /summary

　　private static Dictionarystring, ModelDes _ModelDesCache = new Dictionarystring, ModelDes();

　　缓存操作主要方法如下：

　　View Code

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

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

　　//动态参数类缓存

　　protected static Dictionarystring, Type DynamicParamModelCache = new Dictionarystring, 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扩展系列告一段落，谢谢大家的。

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

　　(责任编辑：admin)