如果启用了连接池，则实际上连接始终是打开的。连接的唯一区别是连接是返回到池还是正在使用中。关闭它会将其返回到池中，但仍然会打开连接。这是正确的吗？如果是这样，
- 然后我认为在使用连接池时调用Connection.Dispose（）总是不好，
因为处理就像破坏连接一样，实际上你只想将连接返回到池中。 下次使用池中的连接时，它会非常快，因为该连接仍然依赖于在池中保持打开连接所需的资源。您不希望从池连接以重新获取所需的非托管资源，因为这会降低性能。 所以关键是，让sqlconnection坚持资源 - 管理或非管理的资源，只要它在池中。这听起来合适吗？当我们处理一个对象时，这意味着我们不想重用它，但是在这里我们打算在池中使用连接，所以为什么要将它们丢弃。
答案 0 :(得分：0)
我很确定你的权利。几年前我在IDisposable上进行研究和撰写文章时，我使用反射器跳入框架，与许多其他具有替代方法的IDisposable对象不同，例如Close（）或Free（）只调用Dispose（），反之亦然， SqlDbConnection对象执行不同的操作，其中一个是集合池。
不幸的是，因为“using”结构很容易使用，所以现在很多代码示例都在“using”表达式中创建了数据库连接，通常在一组嵌套使用中最常见。
你可以用“try”和protected“finally”来实现相同的功能，你可以检查连接是否为null并且在调用close之前打开它。这是VB程序员在获得“using”关键字之前必须这样做的方式。
另一种方式，虽然我肯定会提出一些批评建议，但是将连接包装在另一个瘦IDisposable对象中，该对象接受并公开IDbConnection对象并在包装器内的连接上调用Close（）Dispose（） 。它没有正确遵循IDisposable模式，但是如果你知道为什么这样做，理解影响，而不是将它隐藏起来（不是导出代码或声明行为），那么我真的不能看到问题。我最后一次使用这个技巧时，我把它作为泛型类型，这样我就可以点击具体的DB Connection类型，而不需要为那些不接受IDbConnection的functoin投射它。