【发布时间】：2016-06-22 19:23:57
【问题描述】：
什么时候应该使用 Dapper 而不是 ADO.NET？
我想了解 Dapper 相对于 ADO.NET 的优缺点。 Dapper 的哪些优势会促使其使用？
【问题讨论】：
-
您可以在这里查看性能基准和使用简单性exceptionnotfound.net/…
【发布时间】：2016-06-22 19:23:57
【问题描述】：
Dapper 只是一个工具。它的作用是：
- 使正确参数化查询变得非常容易
- 让执行查询变得非常简单（标量、多行、多网格和无结果）
- 让将结果转化为对象变得非常简单
- 非常高效和快速
它不做的是：
- 为您生成类模型
- 为您生成查询
- 跟踪对象及其更改，以便您只需致电
SubmitChanges()（或其他）
原始 dapper 库不提供 CRUD 功能，但“contrib”附加包确实提供基本 CRUD。
基本上，它不是一个全权重的 ORM，但如果您只想运行查询而不必与 ORM 或支付与 ORM 相关的开销，它非常棒.如果您不了解 SQL，那么原始库可能不适合您（不过“contrib”应该没问题），但是很多人不仅知道 SQL，而且还想控制 SQL（而不是让 ORM 对您的意图做出一些尚未优化的解释等）。
总而言之，原因可能是：
- 您希望以最小的开销获得出色的原始执行性能
- 您希望保留对 SQL 的控制权
- 您不需要也不想要全脂 ORM 的对象跟踪功能
至于“vs ADO.NET”：
- 原始 ADO.NET 涉及 很多 更多代码需要编写和很多边缘情况需要记住（dapper 在内部处理而无需您担心它们）
- 但它实际上并没有更快 - dapper 在完成查询所需的操作后会执行大量元编程来存储和重用策略
- 如果您正在使用原始 ADO.NET 中不可用的特定于提供程序的功能（例如，传递/获取
SqlGeometry数据），那么这些在 dapper 中直接不可用 - 您需要实现一个接口来告诉它如何处理您的场景，但这并不难（请注意，特定的SqlGeometry示例由额外的 dapper 库处理）
【讨论】：
-
另一个不同之处在于，Dapper 使使用参数化查询变得如此简单，以至于人们忘记了通过连接语句和原始值来引入 SQL 注入错误。
-
@PanagiotisKanavos 好吧，我把它包括在第一个项目符号的“正确”中:)
-
也不进行类型检查。
-
@EhsanSajjad 它不能比它所在的原始 API 更快；但是，它可以比典型的 ADO.NET 使用代码更快 - 大多数使用 ADO.NET 的代码往往写得不好、效率低下等；甚至不要让我开始
DataTable:) -
@stt106 定义“测试”。如果您的意思是 unit 测试：那么坦率地说，这是不相关的 - 无论您使用 what 数据访问机制，您都必须将其抽象为纯单元测试；如果您的意思是 集成 测试，那么 Dapper 对此非常满意。所以：没有以任何与测试相关的方式添加额外的障碍。如果您的意思更具体，请告诉我您的想法。