EF 和Dapper的区别

EF:重量级ORM的代表

优点：

1.面向对象的方式操作数据库。

2.能够摆脱sql,完全不用关心sql怎么写，可移植性强。

3.EF支持和适配了所有流行的关系型数据库，并且是面向接口的设计，并对事物，缓存（一级缓存）有良好的封装及配置。

4.支持code first。开发人员可以完全不用关心数据库，代码先行，极大的节约开发成本。

5.开发效率非常高，结合linq，开发速度极快。

6.可以跨数据库，只需要在配置文件中修改连接字符串就能轻松支持。

7.与vs结果的比较好。

缺点：

1.比较复杂，学习曲线大。

2.不适合统计查询系统，效率不是很高。

3.对于多表联查，一些复杂的查询实现比较复杂和困难，而且有可能要借助其他方案来实现。

4.自动生成的sql查询效率略低（效率低，数据量达到一定量级比较明显）

5.对于大量数据，高负载场景需要慎重使用。

6.实现良好的耳机缓存很困难，并且只能定制。

7.EF的Context上下文不是线程安全的，开发人员切记不应该在整个Service上使用一个Context上下文。

8.EF的性能表现比较一般。性能不如ADO，无法控制SQL语句的生成，频繁的插入操作不适用，EF不支持大数据Bulk插入。

Dapper:轻量级ORM的代表

优点：
　　1.开源，轻巧，单文件，上手容易　　
　　2.支持主流的关系型数据库，如SQLserver,MySql,Oracle等。
　　3.执行的效率高，Dapper的速度和原生的IDateReader接近，取列表的数据甚至超过了DateTable。Dapper的原理通过Emit反射IDataReader的序列队列，来快速的得到和产生对象。性能提升了很多
　　4.Dapper实际上是扩展了IDbConnection,提供了一些的查询和执行方法,对ADO.NET的访问对象进行了最底层的封装,所以性能接近ADO.NET

缺点：
　　1.半自动的ORM，需要开发人员自己写实体
　　2.开发的世界成本高，较弱的LINQ支持
　　3.维护成本高，不支持code FIrst.开发人员除了维护好数据库中的表，还得维护好代码中表的映射对象。

下面是我自己的一些经验总结（EF效率问题）

1.EF在查询条件比较的多的时候，转换sql比较耗时，转换为的sql语句比较复杂，查询条件嵌套比较多。

2.在查询的时候，碰到聚合函数，日期等条件的时候，会导致索引失效。

3.查询时，比如查询分页等情况，有时候会调用多次数据库。

4.在直接用Skip和Take时，会导致在内存中分页，先查询全部，在取出分页数据