5

プロジェクトを開始していますが、データ アクセス レイヤーのアーキテクチャに苦労しています。基本的に、異なるデータベース設計を持つ複数のバックエンドとのインターフェースが必要になります。

共通の DAL が必要です。これにより、任意のバックエンドで共通の関数が実行されます。バックエンドには、挿入、更新などのための固有のコードがあります。したがって、1 つのバックエンドで従業員を追加すると、別のバックエンドでは異なるコードになります。

リポジトリ パターンを試しましたが、状況には当てはまりません。Factory パターン メソッドだけで終了しましたが、オブジェクトごとに Factory を作成することになります。ファクトリを 1 つしか作成できないかもしれませんが、Backend オブジェクトには「SaveEmployee」、「SavePlan」などの何百もの関数が含まれることになります。

現在、私は次のものを持っています：

DAL
    --> DAL.Backend1
        --> Employee.Save(employee)
        --> Plan.Save(plan)
    --> DAL.Backend2
        --> Employee.Save(employee)
        --> Plan.Save(plan)

DAL プロジェクトでは、どの DAL のオブジェクトを返して実行するかを決定するために、オブジェクト、従業員、計画ごとに Factory パターンがあります。

これはこれに最適なアーキテクチャではないと確信しているので、問題を解決するために使用するより良いパターンがあるかどうか疑問に思っています。

4

1 に答える 1

0

この機能をプロジェクトの 1 つに実装しました。それが最善の解決策かどうかはわかりませんが、今のところうまくいっています。ただし、CRUD クラスを生成する CodeSmith テンプレートに基づくカスタム DAO レイヤーがあります。基本的に、すべてのユーザーの接続ブローカーを表すシングルトンを作成しました。ユーザーがログインすると、接続先のデータベースを選択します (ただし、一部の IP フィルタリングではオプションが絞り込まれますが、理想的には 1 に絞り込まれます)。ログインは関連付けられたユーザーに接続トークンを格納し、生成された DAO レイヤーの基本クラスは接続ブローカーを呼び出して適切な接続文字列を取得します。そうすれば、DAO オブジェクトが呼び出されるたびに、DAO オブジェクトが DB への接続を試行する前に接続文字列が収集されます。

于 2013-01-24T20:56:47.843 に答える