|
经过前面三个系列的扩展，功能已经全部实现。不过也暴露了很多不足，主要体现在代码混乱有些地方重复处理，更重要的是性能比较差。
今天就从这两方面下手，尽可能的解决这些问题。
代码优化
主要内容如下：
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扩展系列告一段落，谢谢大家的。
说明：程序中如存在错误与不合理请指正，在此谢谢！
|
