いくつかのメソッドを含む単純な静的クラスがあります。これらの各メソッドは、SqlConnectionを開き、データベースにクエリを実行して、接続を閉じます。このように、私は常にデータベースへの接続を閉じると確信していますが、一方で、常に接続を開いたり閉じたりするのは好きではありません。以下は私のメソッドがどのように見えるかの例です。
public static void AddSomething(string something)
{
using (SqlConnection connection = new SqlConnection("..."))
{
connection.Open();
// ...
connection.Close();
}
}
メソッドが静的クラス内にあることを考えると、単一のSqlConnectionを含む静的メンバーが必要ですか?いつ、どのようにドロップする必要がありますか?ベストプラクティスは何ですか?
いいえ、必要がない限り、静的なSqlConnection
を保持しないでください。スレッド化は1つの懸念事項ですが、さらに重要なことですが、通常は必要ありません。提示されたコードでは、内部接続プールは、ほとんどの場合、(同じ接続文字列を使用している限り)連続する呼び出しで同じ基本接続を取得することを意味します。プール担当者に任せましょう。コードはそのままにしておきます。
これにより、2つのスレッドを開始したときに何が起こるかという問題も回避されます...それぞれが独自の接続で作業できるようになりました。静的([ThreadStatic]
を使用しないと仮定)では、同期する必要があり、遅延が発生します。再入可能性は言うまでもありません(つまり、1つのスレッドが同じ接続を同時に2回使用しようとします)。うん;コードはそのままにしておきます。今は問題ありません。ほとんどすべての変更を加えると、問題が発生します。
Open()とClose()を呼び出すと、SqlConnectionに接続プールがあるため、サーバーへの物理接続を実際に開いたり閉じたりすることはありません。使用可能な接続のプールから接続を追加/削除しているだけです。このため、コマンドの実行後、できるだけ遅く接続を開き、できるだけ早く接続を閉じることをお勧めします。
コードサンプルでは、usingブロック内にコードが存在するため、接続オブジェクトでclose()メソッドが自動的に処理されるため、close()メソッドを呼び出す必要はありません。
ほとんどのプログラマーは、遅く開いて早く閉じると信じています。これは、毎回接続を開いたり閉じたりするための待ち時間によってアプリケーション全体の速度が低下する場合にのみ問題になります。
静的クラスを使用する場合は、毎回接続を開いたり閉じたりするのがおそらく最善です。
あなたはベストプラクティスを行っています。クエリを実行する直前にのみ開き、できるだけ早く閉じてください。この種のことは最初は無駄に思えるかもしれませんが、実際にはアプリケーションを長期的にはよりスケーラブルにします。