23

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

我问是因为我和一位同事一直在反复讨论连接池在幕后发生的事情的性质，以及在多个命令之间保持连接打开或打开和关闭它是否有任何好处对于每个命令。

4

3 回答 3

36

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

原始（过时）答案：

你没有错。我没有注意到这种不便的原因是，由于遗留原因（特别是：我们曾经专门使用 LINQ-to-SQL），我们的主要类似连接的东西是DataContext- 所以我们将 dapper 方法重新公开为扩展方法DataContext.

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

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

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

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

所以：我们显然完全感受到了你的痛苦，但我们更进一步地实施了它。

请将此记录为功能请求。我们拥有所有代码（尽管我需要稍微调整一下以适应非缓冲数据的“阅读器”）——dapper 绝对没有理由不能拥有它。

于 2012-09-27T20:01:04.410 回答
3

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

我在同事的代码审查中发现了这一点，强调我在通过 dapper 调用数据库之前没有明确调用 connection.open。这没有被采纳，因为我的集成测试都是绿色的，在运行时一切都是笨拙的。所以我们深入研究了 Dapper 代码。有人可能会争辩说，为了明确性而调用 open 更好，但相反，有些人可能会争辩说代码越少越好。

于 2014-04-02T11:26:14.057 回答
-1

我相信 Dapper 不会管理您的连接，因为它超出了它作为 ORM 映射器的职责。Dapper 不知道您以后是否会重用相同的连接 - 这就是它接受连接作为参数之一的原因。这同样适用于事务 - 应该管理它的是应用程序，而不是 ORM 映射器。

编写自己的管理连接的扩展方法很简单。

于 2012-09-27T19:56:34.833 回答