如果連接池處於打開狀態，則連接實際上始終處於打開狀態。連接的唯一區別是連接是返回到池還是正在使用。關閉它將它返回到池中，但連接仍然打開。這是正確的嗎？如果這是真的，在連接池上配置SqlConnection？
- 那麼我想打電話Connection.Dispose（）使用連接池時，總是不好，
因爲處置就像是破壞連接的時候，居然要只返回連接到游泳池。 下一次使用池中的連接時，該連接將非常快速，因爲該連接仍然需要爲池中的剩餘連接保留所需的資源。您不希望池中的連接重新獲取所需的非管理資源，因爲這會降低性能。 所以問題是，讓sqlconnection堅持資源管理或非管理，只要它在池中。聽起來來嗎？當我們處理一個對象時，這意味着我們不想重用它，但是我們打算在池中使用連接，所以爲什麼要處理它們。
我很確定你的權利。當我在幾年前正在研究IDisposable和關於IDisposable的文章時，我使用反射器跳到了框架中，而不像許多其他具有像Close（）或Free（）這樣的Dispose（）方法的Dispose方法的IDisposable對象，反之亦然， SqlDbConnection對象做了不同的事情，其中之一是收集池。不幸的是，由於「使用」構造非常容易使用，現在很多代碼示例都在「使用」表達式中創建了數據庫連接，通常是一組嵌套使用中創建的數據庫連接。
您可以用「try」和「finally」來保護連接不爲null，並且在調用close之前打開它。這是VB程序員在獲得「使用」關鍵字之前必須完成的方式。
另一種方式，雖然我一定會提出一些批評來暗示它，但是將連接包裝在另一個需要並暴露IDbConnection對象的細IDisposable對象中，並在包裝器中的連接上調用Close（）Dispose ）。它並沒有正確地遵循IDisposable模式，但是如果你知道爲什麼要這樣做，理解影響，而不是隱藏任何人（或者不導出你的代碼或者聲明行爲），那麼我真的不會看到問題。我最後一次使用這個技巧時，我把它變成了一個通用類型，這樣我就可以挖掘具體的DB連接類型，而不需要爲那些不接受IDbConnection的functoins投射它。