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的序列队列来凯苏得到和产生对象。

缺点：

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

---

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

1. EF在查询条件比较的多的时候，转换sql比较耗时，转换为的sql语句比较复杂，查询条件嵌套比较多。
2. 在查询的时候，碰到聚合函数，日期等条件的时候，会导致索引失效。
3. 查询时，比如查询分页等情况，有时候会调用多次数据库。
4. 在直接用Skip和Take时，会导致在内存中分页，先查询全部，在取出分页数据。