2

通常は、DAO クラスが完全に依存するように DAO クラスを構築しようとします。複数のテーブルと対話できますが、データがベース オブジェクトに関連している場合のみです。たとえば、予定オブジェクトがあり、予定 DAO が予定テーブルからデータを取得するとします。予定テーブルが、予定をサービスにバインドする外部キーであるサービス ID である場合、1 つの列を考えてみましょう。サービス テーブルは予定から完全に独立しており、ユーザーがサービスを追加または削除できる独自の DAO を持っています。

予定オブジェクトには、サービス オブジェクトを格納するためのサービス フィールドがあります。これを行ったのは、多くの場合、ビューで予定を処理するときにこのサービス オブジェクトを参照する必要があるためです。

予約 DAO では、別の SQL ステートメントを記述してテーブルからサービス データを取得し、これらすべてを予約 DAO に再マッピングすることができますが、これらはすべてサービス DAO で既に行われており、serviceDao.find を呼び出すのと同じくらい簡単です。 (サービス ID)。予約DAO内でサービスDAOを参照するのは少し汚い気がします。これは設計上の問題があるためですか、それともこの種のことを行っても問題ありませんか? この問題を調査してみましたが、結果は 50/50 です。

4

3 に答える 3

2

1 つのサービス DAO が別のサービスを参照するのはなぜそんなに悪いのでしょうか?

注意が必要な 1 つの懸念事項は、遅延による死亡です。サービスDAOがN個のインスタンスを戻し、それらの結果をループして他のものを戻す場合、N + 1のクエリとN + 1のネットワークラウンドトリップがあり、1つのJOINを使用した1回のラウンドトリップですべてがもたらされますすぐにデータを戻します。

DAO について心配するよりも、できる限り最善で最も効率的な SQL を作成することをお勧めします。

于 2012-10-06T23:25:56.923 に答える
1

特定の「標準」があるかどうかはわかりませんが、私は通常、DAO をエンティティではなくビジネスの意味で編成しています。したがって、通常、予約とサービスが何らかの形で関連している場合、それらをまとめることになるでしょう。おそらく AppointmentServicesDAO のようなものです (それが適切な名前であれば)。エンティティごとにオブジェクトを持つことは、DAO よりもモデルに適しています。

汚いと思うのは同意。私は通常、DAO 内で他の DAO を呼び出すのも好きではありません。クラスに何らかの分離が必要な場合は、おそらくいくつかの基本的な継承が適切です。

しかし、繰り返しになりますが、私は標準をハードコアに勉強したことはありません。主に経験からなので、誰かがより良い提案を持っている場合は、ぜひ聞いてください.

于 2012-10-06T23:09:49.717 に答える
0

他の DAO に属するオブジェクトを ID のみ (この例では「サービス」ID) で参照し、オブジェクト キャッシュを使用して 2 種類のオブジェクトを明確に分離します。

于 2012-11-22T10:56:47.670 に答える