SqlConnectionsをDispose（）しないことはどれほど悪いですか？

個人的には、usingステートメントにIDisposableを実装するADOオブジェクトを配置しないと、ハイブが発生します。しかし、私の現在の契約では、自社開発のエンタープライズフレームワークの「データアクセスプロバイダー」コードは、1）IDisposableを実装せず、2）使用するあらゆるものに対してDispose（）をいつでも呼び出さないことがわかりました。ユーザーは、このフレームワークをデータアクセスに頻繁に使用するWinformsアプリケーションのパフォーマンスの問題について多くの不満を述べています。また、コードにはパフォーマンスに影響を与える可能性のある他の問題がたくさんありますが、他よりも垂れ下がった果物。

だから、「廃棄するのは理由があるのでそれを使う」といったことを言う以外に、これらの人々に、これが本当に、本当に悪いと納得させるように言うことができますか？

あなたができる最善のことは、Dispose() ここでのマイクロソフトのパターンと実践を彼らに示すことだと思います。彼らの目の前にあるこのツールを利用しないことの完全な結果を彼らに見せてください。

SQL接続でDisposeメソッドを呼び出さない場合、使用後にその接続は接続プールに戻されません。

パフォーマンスの問題がある場合、私の推測では、データベース上で最大の接続が開かれています。DBAはこれを簡単に確認できます。

Microsoftのベストプラクティスでは、接続コードをUsingステートメント内に配置し、接続が破棄され、接続がプールに戻されるようにします。

データベース接続プールのサイズには制限があり、いっぱいになると、新しい接続は古い接続が解放されるのを待ちます。それらを使い終わったらすぐに処分しないと、ファイナライザーの実行時に最終的に解放されますが、それは将来の不確定な時間です...だからせいぜい、あなたは新しい接続を開くときに長い遅延が発生します。

最悪の場合、接続プールが無効になっている可能性があります。おそらく、しばらくして、アプリが「接続を待機しているタイムアウト」エラーを返し、接続プールを無効にするとその問題が「解決」したことを発見したのでしょう。しかし、これは毎回まったく新しい接続を作成していることを意味するため、はるかに悪いです-これは驚くほどリソースを消費します。データベースへの何百もの接続を開いている場合、パフォーマンスの問題が発生しているのも不思議ではありません。

これらの問題をすべて解決する正しい方法は、接続が終了したらすぐに破棄することです。最良のアイデアは、必要なだけ接続を開いたままにしておくことです。

深刻なアプリケーションでは、それはかなり悪いと言えます。これらのオブジェクトは、キルパフォーマンスの周りに浮かんでいるだけでなく、単にプロフェッショナルではありません。幸いなことに、Microsoftはオブジェクト階層にFinalizeを実装しています。

~Object()
{
    this.Dispose(false);    
}

public void Dispose()
{
    this.Dispose(true);
    GC.SuppressFinalize(this);
}

protected virtual void Dispose(bool disposing)
{
    // ...
}

取る System.Data.SqlClient.SqlConnection例えば：

System.ComponentModel.Component  <-Finalize disposeパターンを実装します。
    |
System.Data.Common.DbConnection
    |
System.Data.SqlClient.SqlConnection

オブジェクトは最終的に破棄されますが、非決定論的な性質によりパフォーマンスが大きく損なわれます。

まあ、1つには、接続を終了していません。そのため、a）自動的にドロップするか、b）クライアントが使用しなくても循環して更新する必要があります。

b）あなたが説明しているパフォーマンスヒットのためだと思います。ただし、それが唯一の理由ではない可能性があります。

できればクライアント側で接続を閉じる必要がありますが、サーバー側でもフェールセーフを実装する必要があります。それ以外の場合は、データベースサーバーがgod-knows-whenでリリースされるまで処理する必要があるという余分ながらくたがあります。