C# dapper应该使用“using”语句吗？

我见过一些例子，其中有人在做：

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();
}

---

使用Statements的主要目的是释放非托管资源。当对象不再使用时，垃圾收集器会自动释放分配给它的内存，但有时垃圾收集器不会释放资源，如您的示例中的文件、流或db连接

---

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

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

正如其他人正确指出的那样，一般来说，最佳实践是在对象实现IDisposable并且您知道对象的生存期将很短时使用，也就是说，不超过当前方法的持续时间。这样做可以确保及时清理稀缺的操作系统资源。即使一个对象的处理受到其终结器的支持，您也不希望处于这样的情况，比如说，您对一个文件或数据库或其他东西有一个锁，直到终结器从现在开始运行数十亿纳秒后才会释放

---

不过，我想通过说有少数类型实现IDisposable是出于及时处置非托管资源以外的原因来缓和这一建议。在某些非常特殊的情况下，您可以安全地跳过使用。但是，使用using几乎从来都不是错误的，即使严格说来没有必要，因此我给您的建议是，谨慎使用和过度使用，而不是使用不足。

根据我使用ODP.Net驱动程序和MS驱动程序的Sql Server和Oracle的经验，您需要使用using-around-Connections，命令和事务，否则，如果在生产环境中除了最简单的数据库交互之外，您很快就会耗尽连接池—连接池通常是50-200个连接

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

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

---

实际上,，您可以跳过对SqlServer和Oracle参数的使用。

不处理您肯定不会再次使用的资源是一种不好的做法。我知道垃圾收集器的功能，而且我经常看到人们说，using语句应该始终使用，尤其是在连接中使用，以便它们只在需要时保持打开状态，并释放回数据库连接池。当您可以将连接放入using语句中时，为什么要严格依赖垃圾收集器呢。我更关心的是dapper是否会在幕后这么做？为什么要严格依赖垃圾收集器，因为你不能依赖它。@xaisoft我的回答不具体，但它的效果更好，所以无论何时你都要使用Idisposablecan@zerkms-这是一个反问句。是的，在连接处加上一个用法。此外，我想提及Stephen Toub关于处理.Net任务的文章：