针对entity framework的精巧表现

我是新手使用ORM处理数据库,目前我正在制作一个新项目,我必须决定是否使用Entity Framework或Dapper。 我读了许多文章说Dapper比entity framework更快因此我使用Dapper创建了两个简单的原型项目,另一个使用Entity Framework和一个函数从一个表中获取所有行。 表格架构如下图所示

表格式

以及两个项目的代码如下

对于Dapper项目

System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch(); sw.Start(); IEnumerable emplist = cn.Query(@"Select * From Employees"); sw.Stop(); MessageBox.Show(sw.ElapsedMilliseconds.ToString()); 

entity framework项目

  System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch(); sw.Start(); IEnumerable emplist = hrctx.Employees.ToList(); sw.Stop(); MessageBox.Show(sw.ElapsedMilliseconds.ToString()); 

经过多次尝试上面的代码只有我第一次运行项目时,dapper代码会更快,在这第一次总是我从entity framework项目得到更好的结果我也尝试了以下关于entity framework项目的声明来阻止懒惰装载

 hrctx.Configuration.LazyLoadingEnabled = false; 

但是,除了第一次以外,EF的表现仍然相同。

虽然网上的所有文章都相反,但是任何人都可以给出关于EF在这个样本中更快的原因的解释或指导

更新

我已经改变了实体样本中的代码行

 IEnumerable emplist = hrctx.Employees.AsNoTracking().ToList(); 

使用某些文章中提到的AsNoTracking会停止entity framework缓存,停止缓存之后, 精巧的样本表现更好,(但不是很大的区别)

ORM(对象关系映射器)是一种在应用程序和数据源之间创建层的工具,它返回关系对象而不是(就您正在使用的c#而言)ADO.NET对象。 这是每个ORM所做的基本事情。

为此,ORM通常执行查询并将返回的DataReader 映射到POCO类。 小巧玲珑限于此。

为了进一步扩展这一点,一些ORM(也称为“完整ORM”)可以执行更多操作,例如为您创建查询以使您的应用程序数据库独立,为将来的调用缓存数据,为您管理工作单元等等。 所有这些都是很好的工具,为ORM增添了价值; 但它带来了成本。 entity framework属于这一类。

要生成查询,EF必须执行其他代码。 缓存可提高性能,但管理缓存需要执行其他代码。 对于工作单元和EF提供的任何其他附加function也是如此。 所有这些都可以节省编写额外代码的费用,EF可以节省成本。

成本就是性能。 由于Dapper做了非常基本的工作,它更快; 但你必须编写更多代码。 由于EF的作用远不止于此,因此它(比特)更慢; 但你必须少写代码。

那么为什么你的测试结果相反?
因为您正在执行的测试非常基础。 您没有使用EF提供的其他function。 如果您不想使用这些function,为什么不使用Dapper。 如果您想使用这些function,它将根据上述理论略微达到性能。

不是你问题的一部分,但这两者的学习曲线不同也是由于上面提到的相同点。

文章Entity Framework Core 2.0与Dapper性能基准测试,查询SQL Azure表确认Dapper更快,但不足以忽略“完全ORM”的好处。

将它们混合在一起没有问题。 在我目前的项目中,我使用Dapper选择数据,使用EF进行创建和更新以及数据库迁移。

当涉及到涉及两个以上表的复杂查询或者存在一些复杂操作(由多个列连接,加入> =和<=子句,递归选择,cte等)时,Dapper变得非常有用纯SQL比LINQ容易得多。 据我所知,Entity Framework(不像Dapper)不能在自定义DTO上使用.FromSql()方法。 它只能映射应该在数据库上下文中的一个表。