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.开发人员除了维护好数据库中的表，还得维护好代码中表的映射对象。
————————————————
版权声明：本文为CSDN博主「屈先生」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qzh459927216/java/article/details/103233185
下面是我自己的一些经验总结（EF效率问题）
1.EF在查询条件比较的多的时候，转换sql比较耗时，转换为的sql语句比较复杂，查询条件嵌套比较多。
2.在查询的时候，碰到聚合函数，日期等条件的时候，会导致索引失效。
3.查询时，比如查询分页等情况，有时候会调用多次数据库。
4.在直接用Skip和Take时，会导致在内存中分页，先查询全部，在取出分页数据。