EF:重量级ORM的代表
优点：
1、不关心sql怎么写，
2、开发速度快，和linq结合，有效提高开发效率
3、code first，代码优先，不用关心数据库结构，代码先行。
4、跨数据库，只需要把连接字符串改一下就可成功切换数据库
5、与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和Dapper结合使用：
1、Dapper是半自动的ORM，需要开发人员自己写实体，但是和EF结合后实体部分可以由EF来完成。
2、Dapper开发成本高，叫若的linq支持，但是EF和linq结合的非常好，且不用写sql，有效提高开发效率。
3、EF对于多表联查，一些复杂的查询实现比较复杂和困难，而且有可能要借助其他方案来实现（比如联合查询从表属性在主表实体里设为[NotMapped]，查询出来的内容从表属性值为null，可以再写个包含全部属性的实体来解决这个问题，但是过程太过麻烦），
因此这个时候Dapper该上场了! ( dbcontext.Database.Connection.Query<T> ) 完美解决这个问题。
4、传参；利用dapper 的DynamicParameters动态参数查询，结合dapper的dbcontext.Database.Connection.Query<T> （不用string.format()）.
dp.Add(key, value) ; sql里用@key 。传参