为什么Dapper dot net不打开并关闭连接本身？

Question

Dapper隐含地期望连接在使用时打开。为什么不自己打开和关闭它？这不是简单的连接管理吗？

我问，因为我和同事一直在寻找有关连接池的幕后内容的性质，以及在多个命令之间保持连接打开是否有任何好处，或者打开并为每个命令关闭它。

Answer 1

Dapper现在（并且相当长一段时间）在内部处理这个问题。它只是工作™

---

原创（过时）答案：

你没错。我没有注意到这种不便的原因是由于遗留原因（特别是：我们过去常常使用LINQ-to-SQL）我们的主要连接类似于DataContext - 因此我们重新暴露了精致的方法作为DataContext上的扩展方法。

愚蠢的是：这些方法的作用是：

using(db.Connection.EnsureOpen()) {
    db.Connection.{the dapper method}
}

这里的EnsureOpen是一种厚颜无耻的方法：

• 如果连接已打开，则返回null
• 否则，它会打开连接，并返回一个IDisposable令牌，在完成后关闭连接

所以：我们显然感觉完全你的痛苦，但我们进一步实现了它。

请将此作为功能请求记录。我们拥有所有代码（虽然我需要略微调整它以适应非缓冲数据的“读者”） - 绝对没有理由认为dapper不能拥有这个。< / p>

Answer 2

我必须在这里添加一个相反的答案，或者至少建议Dapper可以不同地处理连接，如果仅在某些情况下。我刚刚反映了Dapper.SqlMapper，并且ExecuteCommand方法中有一些检查（由Execute调用（在公共api上））以检查连接是否已关闭然后打开它，如果不是。

我遇到这个，因为我的同事的代码审查突出显示我在通过dapper调用数据库之前没有显式调用connection.open。由于我的集成测试都是绿色的，因此在运行时所有内容都很糟糕。所以我们潜入了Dapper代码。有人可能认为打开明确表示更好，但反过来说有些人可能认为代码越少越好。

Answer 3

我相信Dapper不管理你的连接，因为它不像ORM mapper那样负责。 Dapper不知道你以后是否会重复使用相同的连接 - 这就是为什么它接受连接作为其中一个参数。这同样适用于交易 - 它是应该管理它的应用程序，而不是ORM映射器。

编写管理连接的自己的扩展方法是微不足道的。