EF:重量级ORM的代表
优点:
- 面向对象的方式操作数据库。
- 能够摆脱sql,完全不用关心sql怎么写,可移植性强。
- EF支持和适配了所有流行的关系型数据库,并且是面向接口的设计,并对事物,缓存(一级缓存)有良好的封装及配置。
- 支持code first。开发人员可以完全不用关心数据库,代码先行,极大的节约开发成本。
- 开发效率非常高,结合linq,开发速度极快。
- 可以跨数据库,只需要在配置文件中修改连接字符串就能轻松支持。
- 与vs结果的比较好。
缺点:
- 比较复杂,学习曲线大。
- 不适合统计查询系统,效率不是很高。
- 对于多表联查,一些复杂的查询实现比较复杂和困难,而且有可能要借助其他方案来实现。
- 自动生成的sql查询效率略低(效率低,数据量达到一定量级比较明显)
- 对于大量数据,高负载场景需要慎重使用。
- 实现良好的耳机缓存很困难,并且只能定制。
- EF的
Context
上下文不是线程安全的,开发人员切记不应该在整个Service
上使用一个Context
上下文。 - EF的性能表现比较一般。性能不如ADO,无法控制SQL语句的生成,频繁的插入操作不适用,EF不支持大数据Bulk插入。
Dapper:轻量级ORM的代表
优点:
- 开源,轻巧,单文件,上手容易
- 支持主流的关系型数据库,如
SQLserver,MySql,Oracle
等。 - 执行的效率高,
Dapper
的速度和原生的IDateReader
接近,取列表的数据甚至超过了DateTable
。Dapper
的原理通过Emit
反射IDataReader
的序列队列来凯苏得到和产生对象。
缺点:
- 半自动的ORM,需要开发人员自己写实体
- 开发的世界成本高,较弱的
LINQ
支持 - 维护成本高,不支持
code FIrst
.开发人员除了维护好数据库中的表,还得维护好代码中表的映射对象。
下面是我自己的一些经验总结(EF效率问题)
- EF在查询条件比较的多的时候,转换sql比较耗时,转换为的sql语句比较复杂,查询条件嵌套比较多。
- 在查询的时候,碰到聚合函数,日期等条件的时候,会导致索引失效。
- 查询时,比如查询分页等情况,有时候会调用多次数据库。
- 在直接用
Skip
和Take
时,会导致在内存中分页,先查询全部,在取出分页数据。