EF和dapper

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 。传参