c# - DAL でシングルトン パターンを使用することの長所と短所

Question

DALを実装したシングルトンパターンを使用するように依頼しましたが、接続をプールしたり、トランザクションを使用したりするのは難しいと思います..

長所と短所を知りたいです。また、開発中のサイトには 500 人以上の同時ユーザーがいる可能性があるため、接続をプールする最善の方法も知りたいです。

DB サーバーは Oracle 10g です。

DAL はエンタープライズ ライブラリ 3.1 を使用します

Answer 1

シングルトン パターンは DAL に最適です。私はこれを自分のエンタープライズ Web アプリケーション (数百人のユーザーと 20 のシングルトン クラスで 2,000 以上のメソッド) で使用しています。実際、接続プーリングは、ado.net と SQL サーバー自体によって最適に処理されます。複数のタイプのバックエンド サーバーが必要な場合でも、それは問題ではありません。シングルトン パターンの場合でも、(パラメータ、テキスト/プロシージャ名、資格情報/接続文字列をすべて渡して) 実際にデータベースを直接呼び出す詳細を処理する集中型のデータ アクセス クラスが必要になる場合があります。

私の状況では、単一の各メソッドはデータベース内のストアド プロシージャと 1 対 1 で対応しています。これにより、基本的に各ストアド プロシージャに対して C# の "フロント エンド" フックが作成されるため、構文的に言えば、ネイティブ C# コードとほとんど同じように呼び出すことができます。これにより、DAL への呼び出しが非常に簡単になります。問題のSPが非常に多いため、複数のシングルトンがあります。各 SP には、Development_、Financial_、Organization_ などのプレフィックスがあります。次に、開発、財務、組織など、それぞれに対応するシングルトン クラスがあります。したがって、sp Organization_ViewData は、C# では、Organization という名前のシングルトン クラスの ViewData という名前のメソッドになります。

もちろん、これは 1 つの方法にすぎませんが、この 6 年間で、複数の開発者と大量のコードを処理する方法が非常にうまく機能することがわかりました。主なことは、一貫性が重要だということです。フロントエンド プログラマーがシングルトン ブローカーの 1 つでメソッドの名前を見ている場合、データベース エンドのどこに行くのかを正確に伝える必要があります。そうすれば、問題が発生した場合、またはコードを理解するためにコードを検索する必要がある場合に、実行する必要のあるトレースが少なくなります。

Answer 2

接続プールのベスト プラクティスは、自分で実装するのではなく、ADO.NET フレームワークに任せることです。

接続プール オプションは、接続文字列内のパラメーターとして設定できます。次に、その文字列で開かれるすべての接続は、フレームワークによって実装および管理される接続プールから提供されます。OracleConnection を閉じるか破棄すると、基礎となる接続は破棄されず、代わりにプールに戻ります。

これについては、http: //msdn.microsoft.com/en-us/library/ms254502.aspxで説明されています。

一般的なシングルトンの使用について: データ アクセス層をラップするためにシングルトンを使用しましたが、常にうまく機能しています。

トランザクションは、データベース全体ではなく、特定の接続にのみ適用されることに注意してください。つまり、複数のスレッドを実行でき、各スレッドが個別の OracleConnection インスタンスを使用する場合、各スレッドは独立したトランザクションを介してデータベースの読み取りと書き込みを行うことができます。

Answer 3

DALの場合にシングルトンを使用するのは少し不安です。複数のデータベースバックエンドを使用したい場合はどうなりますか。おそらく、請求書にはMsSQLを使用したいのですが、認証にはActiveDirectoryを使用したいと思います。あるいは、フォーラムの投稿にはMySQLを使用したいのですが、ジオクラスタリングにはPostgreSQLを使用したいと思います（私にとってはもっと現実的です）。シングルトンインターフェイスでは、模擬データベース接続をテストに渡すことができない場合、データベースレイヤーのテストがはるかに困難になる可能性があります。

Answer 4

DAL については知りませんが、シングルトン パターンは、優れたカプセル化を維持しながらデータをグローバルにする優れた方法です。

Answer 5

DAL のデータベース接続ファクトリにシングルトンを使用することは非常に一般的です。多くのコードを変更することなく、ファクトリのさまざまな実装をより簡単にプラグインできます。多くの人はシングルトン パターンを好まないようですが、この種のパターンでは問題なく機能すると思います。

Answer 6

同じメソッドで同時に複数のスレッドを実行できるため、シングルトンを使用するかどうかにかかわらず、パフォーマンスに違いはないと思います。すべてのスレッドで共有される内部フィールドを持たないように注意すると、すべてがうまく機能します。

最後に、接続プールを管理するクラスはスレッドセーフである必要があり、パフォーマンスに影響を与える可能性のあるいくつかのロックを作成することになりますが、それらはすべて必要です。(フレームワーク内で内部的に作成され、とにかく動作を変更することはできません)

シングルトンを使用しないことにした場合は、違いが生じる可能性があるため、DAL インスタンスが軽量であることを確認してください。ただし、通常はそうではありません。

注: 接続プールについて言えば、気を付けなければならない唯一の重要なことは、「遅く開いて、早く閉じる」というパターンに従うことです。つまり、接続を開くのをできるだけ遅らせ、必要な処理をすべて完了したらできるだけ早く接続を閉じます。

この魔法のルールを使用してすべてのシステムを構築したら、接続文字列パラメーターを操作して、いくつかのプール オプション (初期サイズ、最大サイズなど) を変更できます。