26

タイトルで述べたように、特に Web アプリケーション内での DAO パターンの使用について (経験豊富な開発者として) あなたがどう思うか知りたいです。どのような利点があり、その使用のどのような結果が嫌いですか?

4

8 に答える 8

26

私が見た DAO の問題は、通常、完全なオブジェクトを常に処理することです。これにより、単純なクエリでは存在しない、まったく不要なオーバーヘッドが発生します。たとえば、データベース参照データからドロップダウンを作成する場合、DAO ユーザーは単に「y が z で並べられたこのテーブルのオブジェクトのコレクションを取得してください」と言うことができます。次に、そのデータはドロップダウンで使用されますが、通常はキーと値の組み合わせに対してのみ使用され、取得およびマップされたオブジェクト (作成されたデータ、最後に更新したユーザー、アクティブであるかどうかなど) の他のすべては無視されます。 . このマッサージが DAO 呼び出しの近くで発生し、オブジェクトが取得時に格納されない場合でも (通常はそうではありませんが、残念ながら、オブジェクトはしばしば ac:forEach (JSP) でラップされ、繰り返し処理されてドロップ ダウンが生成されます)。 )、

これは、参照データのマップを取得するように DAO を設計できないと言っているのではありません - 確かに可能です。ただし、通常は完全なオブジェクト マッピングに使用されますが、これは常に必要なものではありません。保存するときは強みですが、データを取得するときの弱点、IMO-確かにすべてを取得します-しかし、多くの場合、すべてを必要とするわけではなく、メモリ、帯域幅、および時間を無駄にします.

于 2009-11-17T14:48:23.893 に答える
14

注：他の欠点が見つかるかもしれませんが、ここに私の経験からの簡単なリストがあります

長所：

  • オブジェクトを取得するための一般的な呼び出し。
  • 一般的な作成/読み取り/更新/削除フローを設定すると、他のDAOに対して一般的なレイアウトを繰り返すことができます。
  • また、コードの永続性固有の部分をどこに配置できるかを統合します。ビジネスロジックをコードの他のコンポーネントから分離します。

短所：

  • これまでで最も柔軟なことではありません。
  • 一部の子オブジェクトを遅延ロードする場合は、DAOを他のレイヤーと混合するか、遅延オブジェクトを取得するときに注意を払う必要があります。
  • DAOを手書きすると、コードが面倒で反復的になる可能性があります。
于 2009-11-17T11:41:34.530 に答える
4

DAOパターンの力は、実際のストレージシステムの優れた抽象化レイヤーを作成できることです。これらは、永続層のよりオブジェクト指向のビューを提供し、ドメインと実際にデータアクセスを実行するコード（ストレートJDBC、永続フレームワーク、ORM、さらにはJPA）を明確に分離します。

弱点を引用する必要があるとしたら、それは別のレイヤーだと思います...しかし、これは、コードを基盤となる永続化APIに結び付けないために支払う代償だと思います。

于 2009-11-17T11:38:01.507 に答える
3

DAO パターンを実装に導入することで、いくつかの実際の利点が見られました。これは主に、データベース インターフェイスと実装が明確に分離されているためです。次の利点が確認されています。

  • 実際のデータベース アクセス実装の抽象化により、データ アクセス戦略がユーザー ビジネス ロジックから分離されます。これにより、プロジェクトの初期段階で短期間 (Spring JDBC テンプレート) の実装戦略を選択し、後日 IBATIS または Hibernate に移行するオプションを選択することができました。(現時点では、この選択を行う立場にありません。)
  • この分離により、単体テストでデータ アクセスの実装全体をモックアウトできるという点で、テスト容易性が大幅に向上します。（これが一番のメリットかも）
  • これを Spring と組み合わせることで、任意の DB 実装を選択したシステムに注入できます (ただし、これは DAO パターンよりも DI についての詳細を示している可能性があります)。

私たちが遭遇した問題の 1 つは、これは私たちの側の設計の明確さの欠如が原因である可能性があるため、データベースから発行されたデータ値オブジェクトを、アーキテクチャ内の後続の抽象化レイヤー間で転送オブジェクトとして再利用する傾向があることです。苦労の末の解決策は、レイヤーごとに値オブジェクトを用意することでした (つまり、データベースの値オブジェクトを後続のアーキテクチャ レイヤーで再利用しないことです)。

于 2009-11-17T11:59:14.207 に答える
2

プロ

  • DB テーブルの定義の単一点 - オブジェクト属性マッピング
  • 他のストレージ タイプへの DAO 実装の透過的な可能性
  • すべてのDAOが従うインターフェイスパターンを開発する
  • DAO 用の多かれ少なかれ標準的な JUnit テスト クラスを開発すると、テスト カバレッジが向上します。
  • 詳細を完全に制御
  • 過度に一般的なソリューションによるパフォーマンスの低下はありません

コン

  • 最新のフレームワークを使用するよりも「セクシー」ではありません
  • 開発者は独自の車輪を発明することはできません (プロかもしれません:-))

ほとんどの開発パターンと同様に、DAO の使用には慣れるまでに時間がかかります。経験を積むことで、見た目だけでなく、なぜ機能するのかを知っている、より堅牢なコードと開発者のメリットが得られます。その最後の点は、私にとって最大の利点です。

状況によっては、永続化フレームワークを使用することが、独自の DAO をコーディングする代わりに使用できる場合があります。

于 2009-11-17T12:03:23.000 に答える
2

どのような代替手段を検討していますか?

永続化の責任をプレゼンテーション層以外の場所に置くことが通常は良いことであることは、責任の明確さと再利用の議論から明らかであるように思われます。私は本能的に、プレゼンテーション、サービス、永続性の 3 層アプローチを採用しています。あまりにも長い間この方法を行ってきたので、その方法を行わなかったために苦しんだという証拠を示すことはできません. 私には、永続化メカニズムを理解する単一のレイヤーを持つことは、テストを簡素化し、メンテナンスを容易にし、関心を適切に分離する必要があることは「明らか」に思えます。

そのため、永続化レイヤーを正確にどのように行うかという問題が残ります。私のデフォルトの前提は、JPA (または同様のフレームワーク) を使用することです。私はこれを DAO の洗練された例と見なしています。

したがって、DAO には 2 つのコストがあります。まず、プログラム構造、その設計に投資する必要があります。些細なケースでは、これはやり過ぎのように感じるかもしれません。次に、DAO を実装するフレームワークを使用する場合、学習曲線があります。JDBC コードを直接記述するだけの場合と比較すると、これは別の投資です。

于 2009-11-17T11:56:27.657 に答える
2

長所: 抽象的な分離。
短所：ボイラープレートコード（コードジェネレーター/テンプレートとORMに感謝します）。

于 2009-11-17T11:59:22.770 に答える