私は Hibernate に比較的慣れておらず、DAO を設計するための最適なアーキテクチャ アプローチを理解しようとしています。最初に、一連のドメイン (エンティティ) オブジェクトを作成し、それらにアクセスするための DAO インターフェイスと impl を作成しました。コレクションでエンティティを使用するリスクを軽減するために、主キーを使用しない equals() メソッドと hashCode() メソッドを作成しました。しかし、それは面倒で非効率的であることがわかりました。次に、ドメイン オブジェクトの使用を DAO に限定し、DTO を使用して DAO との間で送受信を行うことにより、この問題を解消することにしました。追加の利点は、テーブル構造から送信/取得されるデータの抽象化と分離であることに気付きました。
ただし、最初から Entity オブジェクトで遊んでいない場合、Hibernate を使用するのは面倒です。たとえば、@OneToMany 関係で依存オブジェクトのリストを書き込む DAO メソッドには、親側エンティティのインスタンスを渡すことができなくなりました。DAO を使用するコードには親の ID があるかもしれませんが、親がないからです。通過するエンティティ。リレーションシップを削除するか、単方向にするか、DAO がエンティティ参照を取得するために親を取得する必要があります。
以前の返信では、DTO はアンチパターンであるとラベル付けされていました。理由がわかります。しかし、Entity クラスの使用が広がれば、私が言及した Hibernate ID フィールドの問題が問題になり、潜在的に危険になるのではないでしょうか? また、返されたデータをテーブル構造から抽象化することには、デカップリングなどの他の利点はありませんか? 複雑なデータ セットが返される場合は DTO が必要になる可能性があるため、DTO を 100% 使用して、前述の利点を得てみませんか?