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_などのプレフィックスがあります。次に、Development、Financial、Organizationなど、それぞれに対応するシングルトンクラスがあります。したがって、C＃ではsp Organization_ViewDataはOrganizationという名前のシングルトンクラスのViewDataという名前のメソッドになります。

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

Answer 2

接続プーリングのベストプラクティスは、自分で実装しないで、代わりにADO.NETフレームワークで処理することです。

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

これは次のとおりです。      http://msdn.microsoft.com/en-us/ library / ms254502.aspx

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

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

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

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

注：接続プールについては、「遅い時間に開く、早い時間に閉じる」に従ってください。パターン。つまり、接続のオープンを可能な限り遅らせ、必要な処理をすべて行った後、できるだけ早く閉じます。

このマジックルールを使用してすべてのシステムを構築した後、接続文字列パラメーターを操作して、いくつかのプールオプション（初期サイズ、最大サイズ、...）を変更できます