dapper 应该使用“使用”语句吗？答案

【问题标题】：Should dapper use a "using" statement?dapper 应该使用“使用”语句吗？
【发布时间】：2015-03-11 01:11:13
【问题描述】：

我见过有人在做的例子：

IDbConnection db = new MySqlConnection(conn);

var people = db.Query<People>("SELECT * FROM PEOPLE").ToList();

或者上述是一种不好的做法，所有查询都应该使用这样的语句：

using (var db = new MySqlConnection(conn))
{
var people = db.Query<People>("SELECT * FROM PEOPLE").ToList();
}

【问题讨论】：

是的，在连接周围使用 using。

标签： c# dapper micro-orm

【解决方案1】：

正如其他人正确指出的那样，一般的最佳实践是在对象实现 IDisposable 的任何时候使用 using 并且您知道对象的生命周期将会很短——也就是说，不会长于当前方法的持续时间。这样做可以确保及时清理稀缺的操作系统资源。即使对象的处置由其终结器“支持”，您也不希望处于这样一种情况，例如，您锁定了文件或数据库，或者在终结器运行几次之前不会释放的东西从现在开始十亿纳秒。

但是我会缓和这个建议，说有少数类型实现IDisposable 的原因不是及时处理非托管资源。在某些非常具体的情况下，您可以安全地跳过using。然而，使用using 几乎从来没有错误，即使严格来说它不是必要，所以我对你的建议是谨慎行事，过度使用，而不是使用不足using。

【讨论】：

另外提一下Stephen Toub关于.Net Tasks的处置的文章：Do I need to dispose of Tasks?

【解决方案2】：

Dapper 对此没有看法；你是using 这是数据库连接。如果您已完成连接：您已完成连接。基本上，是的，您可能应该使用using。

【讨论】：

【解决方案3】：

使用statments的主要用途是释放非托管资源。当一个对象不再使用时，垃圾收集器会自动释放分配给它的内存，但有时垃圾收集器不会释放文件、流或数据库连接等资源就像你的例子一样。

想出一种显式处理对象的方法，而不是将其留给编译器，这样你就可以说这是更好的做法。

【讨论】：

不释放您确定不再使用的资源是一种不好的做法。
我知道垃圾收集器的作用，而且我一直看到人们说应该始终使用 using 语句，尤其是与 connections 一起使用，因此它们仅在需要时保持打开状态并释放回connection pool。当您可以将连接放在 using 语句中时，为什么要严格依赖垃圾收集器。我更关心 Dapper 是否会在幕后这样做？
“为什么要严格依赖垃圾收集器”——因为你不能依赖它。
@xaisoft 我的回答并不具体，但它的效果更好，所以尽可能使用 Idisposable
@zerkms - 这是一个反问。

【解决方案4】：

根据我使用 Sql Server 和 Oracle 的经验（使用 ODP.Net 驱动程序和 MS 驱动程序），您需要使用 using around Connections、Commands 和 Transactions，否则如果您不做最简单的操作，您很快就会耗尽连接池生产环境中的数据库交互（连接池通常约为 50 - 200 个连接）。

您可能不会注意到开发环境中的行为，因为调试 = 大量重新启动，这会清除池。

正如上面的 Eric Lippert 所说，一般来说，在 IDisposable 对象周围使用 using 是一种很好的做法。

在实践中，您可以跳过对 SqlServer 和 Oracle 参数的“使用”。

【讨论】：