DAOパターンの使用の長所と短所
タイトルで述べたように、（経験豊富な開発者としての）DAOパターンの使用について、特にWebアプリケーション内でどのように考えているかを知りたいと思います。どのような利点を見つけ、その使用のどのような結果が嫌いでしたか？
私が見たDAOの問題は、通常、DAOが常に完全なオブジェクトを処理することです。これにより、単純なクエリでは存在しない完全に不要なオーバーヘッドが発生します。たとえば、データベース参照データからドロップダウンを作成する場合、DAOユーザーは単に「yをz順に並べたこのテーブルのオブジェクトのコレクションを取得してください」と言うことができます。次に、そのデータはドロップダウンで使用されますが、通常はキーと値の組み合わせにのみ使用され、取得およびマッピングされたオブジェクト内の他のすべて（作成されたデータ、データを更新した最後のユーザー、アクティブかどうかなど）は無視されます。 。このマッサージがDAO呼び出しの近くで発生し、オブジェクトが取得されたときに保存されない場合でも（通常はそうではありませんが、残念ながら、オブジェクトはac：forEach（JSP）でラップされ、ドロップダウンを生成するために繰り返されます。 ）、これらのオブジェクトを保持するためのメモリの一時的な増加は言うまでもなく、それでも不要なデータベースとネットワークのオーバーヘッドが発生します。
さて、これは、DAOが参照データのマップを取得するように設計できないということではありません-それは確かに可能です。ただし、通常、これらは完全なオブジェクトマッピングに使用されます。これは、常に必要なものではありません。保存するときの長所ですが、データを取得するときの短所であるIMOは、確かにすべてを取得しますが、多くの場合、すべてを必要とせず、メモリ、帯域幅、および時間を浪費するだけです。
注：他の欠点を見つけるかもしれませんが、ここに私の経験からの簡単なリストがあります
長所：
- オブジェクトを取得するための一般的な呼び出し。
- 一般的な作成/読み取り/更新/削除フローを設定すると、他のDAOに対して一般的なレイアウトを繰り返すことができます。
- また、コードの永続性固有の部分をどこに配置できるかを統合します。ビジネスロジックをコードの他のコンポーネントから分離します。
短所：
- これは、これまでで最も柔軟なことではありません。
- 一部の子オブジェクトを遅延ロードする場合は、DAOを他のレイヤーと混合するか、遅延オブジェクトを取得するときに注意を払う必要があります。
- DAOを手書きすると、コードが面倒で反復的になる可能性があります。
DAOデザインパターンを使用する利点
DAOまたはデータアクセスオブジェクトのデザインパターンは、抽象化およびカプセル化オブジェクト指向の原則の良い例です。永続性ロジックを分離するのは、データアクセス層と呼ばれる独立した層であり、アプリケーションが永続性メカニズムの変更に安全に対応できるようにします。たとえば、ファイルベースの永続性メカニズムからデータベースに移行した場合、変更はデータアクセス層に限定され、サービス層またはドメインオブジェクトには影響しません。データアクセスオブジェクトまたはDAOパターンは、JavaアプリケーションがコアJava、Webアプリケーション、またはエンタープライズアプリケーションである場合、ほぼ標準です。以下は、Javaアプリケーション：
DAOデザインパターンはまた、アプリケーションの異なる部分間の結合を低く保ちます。 DAOデザインパターンを使用することにより、ビューレイヤーはDAOレイヤーから完全に独立し、サービスレイヤーのみが依存関係を持ちます。これもDAOインターフェイスを使用して抽象化されます。
DAOデザインパターンにより、モックを作成し、データベースに接続してテストを実行する必要がなくなるため、JUnitテストをより高速に実行できます。データベースとの統合テストではなく、モックオブジェクトを使用したテストを簡単に作成できるため、テストが向上します。問題が発生した場合は、単体テストの実行中に、データベースではなくコードを確認するだけで済みます。また、データベース接続と環境問題を防ぎます。
DAOパターンはインターフェイスに基づいているため、オブジェクト指向の設計原則である「実装よりもインターフェイスのプログラミング」を促進し、柔軟で高品質のコードを実現します。
DAOパターンの力は、実際のストレージシステムのNice抽象化レイヤーを作成できることです。これらは、永続性レイヤーのよりオブジェクト指向のビューと、ドメインと実際にデータアクセスを実行するコード（ストレートJDBC、永続性フレームワーク、ORM、さらにはJPA）を明確に分離します。
弱点を引用する必要があるとしたら、それは別のレイヤーだと思います...しかし、これは、コードを基盤となる永続化APIに結び付けないために支払う代償だと思います。
DAOパターンを実装に導入することでいくつかの実際の利点が見られました。これは主に、データベースインターフェイスと実装が明確に分離されているためです。次の利点があります。
- 実際のデータベースアクセス実装の抽象化により、データアクセス戦略がユーザーのビジネスロジックから分離されます。これにより、プロジェクトの初期フェーズで短期（Spring JDBC Template）の実装戦略を選択でき、後日IBATISまたはHibernateに移行することもできます。 （現時点では、選択することはできません。）
- この分離により、データアクセスの実装全体を単体テストでモックアウトできるという点で、テスト容易性に大きなメリットがあります。 （これはおそらく最大のメリットです）
- これをSpringと組み合わせると、選択したシステムに任意のDB実装を注入できます（ただし、これはDAOパターンよりもDIについて詳しく説明している可能性があります）。
私たちが遭遇した問題の1つは、設計が明確でないことが原因である可能性があります。これは、データベースから公開されたデータ値オブジェクトを、アーキテクチャ内の後続の抽象化レイヤー間で転送オブジェクトとして再利用する「傾斜」です。いくつかの苦痛の後の私たちの解決策は、レイヤーごとに値オブジェクトを持つことでした（つまり、後続のアーキテクチャレイヤーでデータベース値オブジェクトを再利用しないこと）。
どのような代替案を検討していますか？
責任の明確さと再利用の議論から、プレゼンテーション層以外の場所に永続性の責任を置くことは通常は良いことであることはかなり明白なようです。私は本能的に、プレゼンテーション、サービス、永続性の3層アプローチを採用しています。長い間このようにしていたことを告白し、そうしなかったために苦しんでいる痛みの証拠を引き出すことができません。私には、永続化メカニズムを理解する単一のレイヤーを持つことで、テストを簡素化し、メンテナンスを容易にし、関心の分離を適切に行う必要があることは「明らか」に思えます。
したがって、永続性レイヤーを正確に実行する方法の問題が残ります。私のデフォルトの仮定は、JPA（または同様のフレームワーク）を使用することです。私はこれをDAOの洗練された例と見なしています。
したがって、DAOには2つのコストがかかります。まず、プログラムの構造、その設計に投資する必要があります。些細なケースでは、これはやり過ぎのように感じるかもしれません。次に、DAOを実装するフレームワークを使用する場合、学習曲線があります。 JDBCコードを直接記述することと比較すると、これは別の投資です。
プロ：抽象的な分離。
短所：定型コード（コードジェネレーター/テンプレートとORMに感謝します）。
[〜＃〜] pro [〜＃〜]
- dBテーブルの単一の定義ポイント-オブジェクト属性マッピング
- 他のストレージタイプへのDAO実装の透過的な可能性
- すべてのDAOが従うインターフェースパターンを開発する
- dAOの結果のために多かれ少なかれ標準的なJUnitテストクラスを開発することで、より良いテストカバレッジが得られます
- 詳細を完全に制御
- 過度に一般的なソリューションによるパフォーマンスの低下はありません
[〜＃〜] con [〜＃〜]
- 最新のフレームワークを使用するよりも「セクシー」ではありません
- 開発者は自分のホイールを発明することはできません（PROかもしれません:-)）
ほとんどの開発パターンと同様に、DAOの使用に慣れるまでには少し時間がかかります。経験を積むと、見た目だけでなく、なぜ機能するのかを知っている、より堅牢なコードと開発者のメリットがもたらされます。その最後の点が私にとって最大の利点です。
警告、永続フレームワークを使用する状況によっては、独自のDAOをコーディングする代わりに適している場合があります。