如果连接池打开，那么连接实际上是始终打开的。连接的唯一区别是连接是返回到池中还是正在使用中。关闭它会将其返回到池中，但连接仍处于打开状态。这是正确的吗？如果这是真的，
- 那么我认为在使用连接池时调用 Connection.Dispose() 总是不好的，
由于处置就像破坏连接，实际上您只想将连接返回到池中。下次您使用池中的连接时，它会非常快，因为该连接仍然坚持在池中保持打开连接所需的资源。您不希望来自池的连接重新获取它需要的非托管资源，因为这会降低性能。所以关键是，让 sqlconnection 坚持资源 - 托管或非托管，只要它在池中。这听起来对吗？当我们处置一个对象时，这意味着我们不想重复使用它，但是这里我们打算使用池中的连接，所以为什么要处置它们。
我很确定你的权利。几年前，当我研究 IDisposable 并撰写文章时，我使用反射器跳入了框架，与许多其他 IDisposable 对象不同，这些对象具有像 Close() 或 Free() 这样的替代方法，它们只调用 Dispose()，反之亦然， SqlDbConnection 对象做不同的事情，其中之一是集合池。
不幸的是，由于“using”结构非常易于使用，如今的许多代码示例都在“using”表达式中创建了数据库连接，通常是一组嵌套 usings 中最突出的。
您可以通过“尝试”和“最终”保护来实现相同的目的，您可以在其中检查连接是否为空并且在调用 close 之前打开。这是 VB 程序员在获得“using”关键字之前必须这样做的方式。
另一种方法，虽然我肯定会因为建议它而受到一些批评，但是将连接包装在另一个薄 IDisposable 对象中，该对象采用并公开一个 IDbConnection 对象并在包装器 Dispose() 内的连接上调用 Close()。它没有正确遵循 IDisposable 模式，但是如果您知道为什么要这样做，了解影响并且不向任何人隐藏它（不导出代码或声明行为），那么我真的看不出问题。上次我使用这个技巧时，我将它设为通用类型，这样我就可以点击具体的 DB Connection 类型，而无需为那些不接受 IDbConnection 的函数强制转换它。