接続プーリングがオンの場合、接続は実際には常に開いています。接続の唯一の違いは、接続がプールに戻されるか、使用中かということです。閉じるとプールに戻りますが、接続はまだ開いています。これは正しいですか？これが本当なら、
-接続プールを使用する場合、常に Connection.Dispose( ) を呼び出すのは良くないと思います。
破棄は接続を破棄するようなものなので、実際には接続をプールに戻したいだけです。次にプールからの接続を使用するときは、非常に高速になります。これは、その接続がまだプール内で開いている接続を維持するために必要なリソースに固執しているためです。パフォーマンスが低下するため、プールからの接続で必要な非管理リソースを再取得することは望ましくありません。要点は、プール内にある限り、sqlconnection をリソース (管理対象または非管理対象) に固定させることです。これは正しいと思いますか？オブジェクトを破棄するということは、それを再利用したくないことを意味しますが、ここではプール内の接続を使用するつもりなので、なぜそれらを破棄するのでしょうか。
I'm pretty sure your right. When I was researching and article on IDisposable some years ago, I jumped into the framework using reflector, and unlike many other IDisposable objects that had an alternate method like Close() or Free() that just called Dispose() or vice versa, the SqlDbConnection object does different things, one of which was collection pooling.
Unfortuneatly, because the "using" construct is so easy to use, a lot of code examples these days have the DB connection created within a "using" expression, typically as the out most in a set of nested usings.
You could achieve the same thing with a "try" and protected "finally" where you check that the connection is not null and is open before calling close on it. This is the way VB programmers had to do it before they got the "using" keyword.
Another way, though I'm bound to draw some criticism for suggesting it, is to wrap the connection within another thin IDisposable object that takes and exposes an IDbConnection object and calls Close() on the connection within the wrappers Dispose(). It doesn't follow the IDisposable pattern correctly, but if you know why your doing it, understand the impacts, and not hiding it from anyone (either not exporting your code or declare the behaviour) then I can't really see a problem. The last time I used this trick I made it a generic type so that I could tap the concrete DB Connection type without the need to cast it for those functoins that don't accept IDbConnection.