我研究了Dapper和ADO.NET,并对两者进行了选择测试,发现有时ADO.NET比Dapper更快,有时会逆转。我知道这可能是数据库问题,因为我正在使用SQL Server。据说反射很慢,我在ADO.NET中使用反射。那么有谁能告诉我哪种方法最快?
这是我编码的。
DashboardResponseModel dashResp = null;
SqlConnection conn = new SqlConnection(connStr);
try
{
SqlCommand cmd = new SqlCommand("spGetMerchantDashboard", conn);
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.AddWithValue("@MID", mid);
conn.Open();
var dr = cmd.ExecuteReader();
List<MerchantProduct> lstMerProd = dr.MapToList<MerchantProduct>();
List<MerchantPayment> lstMerPay = dr.MapToList<MerchantPayment>();
if (lstMerProd != null || lstMerPay != null)
{
dashResp = new DashboardResponseModel();
dashResp.MerchantProduct = lstMerProd == null ? new
List<MerchantProduct>() : lstMerProd;
dashResp.MerchantPayment = lstMerPay == null ? new
List<MerchantPayment>() : lstMerPay;
}
dr.Close();
}
return dashResp;
DashboardResponseModel dashResp = null;
var multipleresult = db.QueryMultiple("spGetMerchantDashboard", new { mid =
mid }, commandType: CommandType.StoredProcedure);
var merchantproduct = multipleresult.Read<MerchantProduct>().ToList();
var merchantpayment = multipleresult.Read<MerchantPayment>().ToList();
if (merchantproduct.Count > 0 || merchantpayment.Count > 0)
dashResp = new DashboardResponseModel { MerchantProduct =
merchantproduct, MerchantPayment = merchantpayment };
return dashResp;
Dapper基本上跨越了ADO.NET作为一个非常薄的抽象 - 所以理论上它不能比编写良好的ADO.NET代码更快(尽管说实话:大多数人都写不好写的ADO.NET代码)。
但是,它几乎无法区分;假设您只使用Dapper(不是任何位于其上的东西),那么它不包括任何查询生成,表达式树/ DSL解析,复杂模型配置或任何其他倾向于生成的东西完整的ORM更灵活但更昂贵。
相反:它只关注执行用户提供的查询和映射结果;它的作用是通过IL-emit和缓存生成所有物化代码(如何将MerchantProduct
映射到您的列)。同样,它以相同的方式准备了大部分参数准备代码。因此,在运行时,它通常只是从缓存中获取两个委托实例并调用它们。
由于(RDBMS的延迟+查询执行成本+结果的网络带宽成本)的组合将远远高于从字典中提取两个代表的开销,我们基本上可以忽略该成本。
简而言之:您可以在此处测量显着的开销。
作为对代码的次要优化:更喜欢AsList()
和ToList()
以避免创建副本。
Dapper是micro-ORM或Data Mapper。它内部使用ADO.NET。此外,Dapper将ADO.NET数据结构(例如DataReader
)映射到您的自定义POCO类。因为这是Dapper做的额外工作,理论上它不能比ADO.NET快。
以下是从comments(@MarcGravell)之一复制的this答案:
它不能比它所处的原始API更快;但是,它可能比典型的ADO.NET消费代码更快 - 大多数消耗ADO.NET的代码往往写得很糟糕,效率低下等;甚至没有让我开始使用
DataTable
:)
假设在比较时以优化的方式正确使用ADO.NET。否则,结果可能相反;但这不是ADO.NET的错。如果ADO.NET使用不正确,它可能比Dapper表现不佳。这是在使用ADO.NET直接绕过Dapper时发生的情况。
与ADO.NET相比,大多数情况下的Dapper表现相同(可忽略不计)。 Dapper在内部实现了许多针对其范围内的ADO.NET推荐的优化。此外,它强制许多良好的ADO.NET编码实践,最终提高性能(和安全性)。
由于映射是Dapper的核心部分,因此通过使用IL进行了大量优化。这使得Dapper比在代码中手动映射更好。
请参阅此博客,其中介绍了如何发明Dapper以及如何针对性能进行优化:https://samsaffron.com/archive/2011/03/30/How+I+learned+to+stop+worrying+and+write+my+own+ORM
buffered
参数;如果设置为false
,Dapper不会实现列表。它只是在迭代器中将每个项目移交给您。请参阅@Marc对此答案的评论。IDbConnection
编写的。在极少数情况下,这可能会达到性能。但是,如果您实现一个接口来告诉Dapper如何执行此操作,则可以执行此操作。有了这种轻微且罕见的性能,您将获得巨大的好处,包括强类型数据结构和更少且易于管理的代码。这真是一大收获。
在网上有很多性能比较的Dapper(与其他ORM和ADO.NET)的statistics;看看你是否感兴趣。