3

私のアプリケーションでは、複数のテーブルで実行され、すべてのテーブルから情報を返す複雑なクエリを作成する必要があります。

その状況でDAOパターンを使用するにはどうすればよいですか?

CRUD 用の DAO がある場合は非常に単純ですが、複雑なクエリを処理する必要がある場合は混乱します。

すべてのテーブルのこのセット情報を表すオブジェクトと、この特定のビジネス オペレーション用の DAO を作成する必要がありますか?

または、テーブルごとに DAO を用意し、オブジェクトを返す各 DAO でこのクエリを分離する必要があります。最後に、その複雑なクエリを表す多くのオブジェクトが得られますか?

それとも別の選択肢がありますか？

DAO クラスは、データベース内のテーブルまたはビジネス クラスと直接リンク (表示) する必要がありますか?

前もって感謝します！

4

2 に答える 2

4

どのパターンが役立つかを判断する前に、次の要因を検討する必要があります。例えば：

  1. アクセスされるテーブルの数とパフォーマンスの重要性は?
  2. このオブジェクトは読み取り専用ですか、それとも更新する必要がありますか?

これらの要因を考慮して、パフォーマンス要件があり、このオブジェクトで CRUD を実行する必要がある場合は、このオブジェクトに単一の DAO を選択できます。また、読み取り専用でパフォーマンスが大きな制約にならない場合は、複数の DAO からこのオブジェクトを構築できます。

于 2013-03-13T02:11:29.613 に答える
0

あなたはあなたのビジネスオブジェクトが何であるか、そしてそれらの関係が何であるかをもう少し説明するかもしれません...

ただし、設計に関する限り、一般的なオプションの1つは、CRUDを実行するテーブルごとにクラスを作成してマップすることです。これらのクラスには、それぞれのテーブルの列と一致するプロパティがあります。

テーブルごとにDAOも作成するかどうかはあなた次第ですが、（おそらく実装言語によっては）CRUDメソッドを実装する単一の汎用DAOを作成することもできます。

より複雑なエンティティ関係を考慮した別の設計は、ビューとストアドプロシージャを作成し、それらにマップすることです。これにより、特定のテーブルで1対1で明確に表現されていないオブジェクトを作成できるようになります。このアプローチにはいくつかの利点がありますが（たとえば、データベースの設計をアプリケーションから遠ざけることができます）、欠点もあります（ビジネスロジックをデータベースに移動することは望ましくない場合があります）。

于 2013-03-12T14:44:55.640 に答える