1. 写在前面的话
一直没有写博客的习惯，感觉太浪费时间，没有那么多精力，其实仔细一想，写博客是一种习惯，也是一种心境，同时也是对自己所掌握的知识结构的一个梳理过程，对自己知识体系的一个巩固，同时也是对自己所掌握的技能融会贯通灵活运用的体现，所以接下来打算利用一些业余时间写写博客，博客中某些观点和见解纯属个人经验和见解，可能不对，或者不够准确，还请大家多多指导，如果您能指出我不对的地方我一定非常感谢您，我会不断改进。不断向您请教学习。
2. 切入正题
EF全称Entity Framework，大家都只EF是微软原生的ORM框架，但一直以来不是很受欢迎，具体原因不详，但是凭个人经验和周围同行的呼声大致可以得知，一个非常重要的原因就是很多人质疑EF的性能，认为面对大数据量的增删改查时，EF的性能是一个非常重要的瓶颈，在EF5及其以前版本的确如此，但是经过微软不断的优化重构，以及某些爱心人士和权威机构的扩展，微软推出的EF6以及某些爱心人士和权威机构推出的EF的一些扩展，使得EF的性能得到大大改善，本文不是讲一些概念性的东西，也不是去讲太深层次的原理机制等，本文主要介绍EF6及其相关扩展与主流ORM 框架Dappe的性能对比。
3. 环境配置
1.电脑配置
2.软件环境
Vs2013 update 4,SQL Server 2014, EntityFramework 6.1.3,
4. 测试情况
本文重点是测试EF的性能，所以也不用具体去讨论使用场景，具体场景大家具体选择就可以了，本文考虑最理想的情况下测试，对EF中影响增删改查的效率的因素全部排出，即：对EF的上下文做一些配置以减少性能的损耗：
Configuration.AutoDetectChangesEnabled = false;
Configuration.ValidateOnSaveEnabled = false;
Configuration.LazyLoadingEnabled = false;
Configuration.ProxyCreationEnabled = false;
具体含义根据英文名称就可以知道，这里不用做过多的解释，废话不多说，直接看结果。
5. 批量数据插入测试性能测试对比
6. 批量数据更新测试性能对比
7. 批量数据删除测试性能对比
8. 查询测试性能对比
9. 测试结论
本文所用数据库比较大，不方便上传，所以上传到群共享，大家可以到群共享下载测试。
测试都是从一个库取出数据插入另一个库，然后在新的库中做操作，而且在增删改之前都要对新库中的数据做清除，所以批量插入数据或者批量更新数据实际上是做了清除数据，取数据，插入数据三个步骤，实际环境中清除数据，取数据属于操作前准备，所产生的性能损耗应该另外计算，所以实际环境增删改应该会更快。
另外曾经在做ADO.NET封装的时候测试过对于批量插入数据，采用分组提交事务的将分组平衡点（一次插入的条数）设置为500时，效率最高，而本文中采用dapper批量插入数据，不管插入多少条，我都一次性插入，不清楚dapper内部有没有做分组提交封装，没有研究过内部实现，所以，实际应用中如果对dapper也做分组提交事务的话，性能可能还会有很大的提高。
从测试的速度上来看：对于插入数据，从清除数据，再取数据，插入到表中三步操作EF6扩展的批量操作比dapper快4倍左右；而对于批量删除和更新，也是先清除表中的数据再从一个大表中取数据插入新表中进行删除和更新测试，当然不管是EF还是dapper前批量操作的前两个步骤（清除数据，再取数据插入到表中）都是用同样的方法执行，而且速度非常快，对批量删除和批量更新的影响相同，所以对于批量删除和更新相当于给EF和dapper同时加上一个非常小的时间，对测试结果不会有太大的影响，测试结果也是EF6扩展的批量删除和更新操作比dapper快4倍左右，当然也有可能dapper方法没有用对，所以才导致dapper性能比EF6扩展的还要低。
对于查询，本文都是针对同一张表，表中的测试数据有76万左右数据，同时采用了默认EF查询，EF AsNoTracking无跟踪查询，dapper查询和各种形式的DataReader查询，经过多次的测试都是DataReader最快，EF6 No Track，DataReader for Expression Mapping，Dapper三者随机排名，旗鼓相当，不分伯仲。
10. 注意:
AsNoTracking是无跟踪查询, 有时我们的实体只需要显示，无需更新，所以为了提高性能，我们不需要实体被EF追踪。此时可以使用AsNoTracking的查询来得到实体，这样实体的状态是Detached状态。这样可以提高性能，但是如果取到数据后，要对数据做修改并保存，则无法反映到数据库里。另外如果对通过AsNoTracking，得到的数据做删除处理，还会报错。