Dapper与Entity Framework：为您的 .NET 项目选择正确的ORM

当谈到 .NET 中的对象关系映射（ORM）时，通常会考虑两种流行的选项。Dapper 和 Entity Framework 都允许开发人员以面向对象的方式处理数据，但它们存在差异，当您在正确的地方使用它们时，它们可以让您的生活更轻松。

在这篇文章中，我试图帮助我的读者为他们的下一个项目选择合适的ORM。这并不意味着让其中一个 ORM 看起来很糟糕，而另一个看起来不错;同时，我必须对我使用这些 ORM 所经历的不同好处和痛苦发表诚实的意见。

查询语言

在 Dapper 中，你应该使用原始 SQL 查询，如果你熟悉 SQL，这是个好消息，而且这些查询在 Visual Studio 中是纯文本，因此你的查询没有 IntelliSense 或颜色编码。对于实体框架，可以使用名为 LINQ 的查询语言编写查询，该语言非常丰富且易于用于复杂查询，特别是对于 SQL 经验有限的开发人员。在决定哪个 ORM 更容易查询时，这在很大程度上取决于开发人员的经验。根据我个人的看法，用 SQL 本身而不是 LINQ 编写查询更容易，因为当涉及到复杂的查询时，尤其是对于设计得不是很好的数据库，阅读和维护 LINQ 变得非常困难，但 SQL 感觉更自然。在 Visual Studio 中没有任何帮助非常烦人，绝对是 Dapper 的缺点，但您可以在更友好的环境（如 SSMS for MSSQL）中编写查询，并将最终版本复制到 C# 代码中。

在下面的示例中，您可以看到，对于更复杂的查询，LINQ 很快就会变得更难阅读。

SELECT   
p.*,   
COUNT(DISTINCT oi.orderId) AS orderCount,   
SUM(oi.quantity * oi.price) AS revenue   
FROM Products p   
LEFT JOIN OrderItems oi ON p.id = oi.productId   
GROUP BY p.id

现在，LINQ 版本：

var products = dbContext.Products  
.Select(p => new {   
Product = p,   
OrderCount = p.OrderItems.Select(oi => oi.Order.CustomerId)  
.Distinct()  
.Count(),   
Revenue = p.OrderItems  
.Sum(oi => oi.Quantity * oi.Price)   
})  
.ToList();

性能

在没有基准测试来支持您的声明的情况下谈论性能不是很准确，并且 EF 版本可能会根据使用的版本在基准测试中产生不同的结果。也许这将是另一篇文章的一个很好的主题，但今天我想谈谈我个人经历的表现。在我看来，如果你在简单的查询中比较它们，它们都会有接近的结果，但是当查询变得庞大而复杂时，Dapper 是赢家。

Entity Framework 是一个功能齐全的 ORM，如果您不打算真正使用这些功能，那么它有很多可能会减慢您使用数据库的速度，因此不值得将这些功能与性能进行交易。

Dapper 不具备的实体框架功能

延迟加载：在代码中访问实体之前，不会从数据库中检索实体。

代码优先开发：可以使用批注在 C# 代码中定义 SQL 架构，并要求 EF 在数据库中实现它们。

查询缓存：将经常执行的数据库查询存储在内存中，通过减少数据库的往返次数来提高性能。

更改跟踪：跟踪对内存中对象所做的更改，并自动生成 SQL 语句以相应地更新数据库。

调试问题

有时调试 Entity Framework 并不容易，因为你不知道最终查询是什么，尤其是当你遇到性能问题时，但你总是可以记录生成的查询并在那里找到问题，但你对生成的查询的确切控制有限。另一方面，当您使用 Dapper 时，您可以准确地看到针对数据库运行的内容，并且可以在项目中使用它之前测试性能。

为您的 .NET 项目选择正确的 ORM

当您想在这两个 ORM 之间进行选择时，您需要问自己一些问题才能做出正确的决定。以下是我在开始项目之前问自己的问题。

数据模型和查询的复杂性如何？
您的应用程序的性能要求是什么？
您在编写 SQL 查询方面有什么经验？
您的项目是否需要代码优先开发，或者是否可以使用现有的数据库架构？
应用程序需要哪些特性和功能，是否要使用 Entity Framework 具有的功能？

在进行了所有技术比较之后，我认为了解您的团队成员拥有哪些技能以及哪种 ORM 适合他们很重要。无论如何，如果你选择了 Entity Framework，而你的团队无法正确使用这些功能，或者你使用 Dapper 并且你的团队不知道如何编写好的 SQL 查询，你就不会得到一个好的结果。