ORM 的本质比较简单，就是对象关系映射 Object Relation Mapping
那很多人都经常会说的一个问题，EF 或 EF Core 好啊，方便啊，不用写麻烦的 SQL ，写 SQL 又要提高成本（初级程序员的学习成本）又会降低代码可读性。
我个人总结的经验就是不用纠结太多，看项目，也看侧重点。
用 EF / EF Core 好处：
1. 上手快，开发容易，LINQ & Lambda 写法可读性高
2. 学习成本低（很重要）
缺点也很致命：
1. 不易掌控，很容易写出效率极低的 LINQ 导致拖死 DB。
2. 过度屏蔽细节，真的要用好 EF 需要深入了解其内部架构
3. 依赖官方更新，如果存在 BUG 或优化，没有非常了解的小组，很被动
个人推荐的使用场景：
1. 公司有几个或1个专门的小组对 EF / EF Core 有深入研究，并且可以做二次开发
2. 中小型，内部项目，并且不存在性能要求（高并发，大数据量的数据查询，DB压力很小）也可以用
Dapper + Sql 好处（推荐）：
1. 快，稳，可控性高（细节把控） 。
2. 可扩展性强，毕竟就那么点东西，不过需要懂 Emit，不写 Emit 封装可能存在性能问题，毕竟 ORM 需要做大量反射。
3. 有实际项目在用，Stackoverflow 那么大的并发量都能抗住，说明本身是一个优秀的开源项目。
缺点：
1. 首先需要学 SQL ，虽然不是一门语言，但是是一个必要技能，有一部分初学者接触过 EF 后，产生一种不需要写 SQL 的感觉。目前来讲不是很赞同（以后可能会有 AI 分析，我也不确定）
，程序员，就是要有知其然知其所以然的精神，至少自己写的 SQL，自己知道 SQL 执行了哪些东西，分析问题也容易（总不至于连发现几个 SQL 查询非常慢，你一脸大写懵逼，还要去找 DBA 帮忙）。
2. 需要合理的写 SQL，如果写在代码中，会降低代码可读性（如果 SQL 比较长）
3. Dapper 本身只做了 ADO.Net 的封装，所以你需要比写 EF 做更多的事情，比如连接池管理。
个人推荐场景：
1. 对 SQL 性能有一定要求（甚至有些公司有非常严格的要求，查询用时要精确到毫秒），并且经常需要分析 SQL 日志做数据库方面的优化。
2. 团队中对写 SQL 不排斥，毕竟不能强人所难吧，有一些人确实不喜欢写 SQL （虽然我不这么认为）。
3. 数据量很大，并发也不小，但又不是很想在 ORM 这个方面做过多投入。