多くのサンプルを調べましたが、これに対する適切な解決策が見つかりませんでした。一部のドキュメントには、「理想的には、ビジネス ロジック レイヤーはデータベースの存在を認識すべきではありません。接続文字列や SQL について認識すべきではありません」と書かれています。
ビジネス ロジックを @Service アノテーション付きクラスに配置するサンプルをいくつか見つけましたが、@Service メソッドで SQL/HQL を使用しています。
理想的な使い方とは？データベースまたは永続化テクノロジを変更したい場合、@Repository アノテーション付きクラスのみを変更する必要がありますか、それとも両方を変更する必要がありますか?
理想的には、ビジネス ロジックは、ドメインをモデル化するオブジェクトを処理するか、ドメインをモデル化するオブジェクトで構成されます。永続性などの問題を認識すべきではありません。それが、Hibernate のような O/R-Mapper のすべてです。ビジネス ロジックは、ドメイン属性 (従業員名、先月の収益など) に基づいて、必要なオブジェクトを要求します。
パーシスタンス レイヤーは、ビジネス デマンドを SQL/HQL/サービス コール、または使用されているテクノロジーが必要とするものに変換できる必要があります。したがって、ビジネス ロジック レイヤーは、ビジネス ロジックが変更された場合にのみ変更されます。
理想的な世界ではそれが目標になりますが、実際には、重要な問題にはうまくいきません。ある程度の結合を避けることはできません。しかし、@JB Nizetが言ったように、カップリングを妥当な量に減らすことは報われます。TDD を使用し、SRP などの OO 原則を順守することで、そこにたどり着くことができます。
サービス メソッドでは、SQL/HQL 構文やデータベース作業を使用しないでください。それらはすべて、@Repository として注釈が付けられた DAO レイヤーにある必要があります。サービスメソッドから呼び出すだけです。このようにして、将来、データベースを簡単に変更できます。そうしないと負担が大きすぎる
私はすべての永続性関連のもの (つまり、クエリ、および JDBC、JPA、または Hibernate を扱うすべてのもの) を DAO 層に置き、サービス層を永続性関連のもののためにこの DAO 層に依存させることを好みます。
ただし、主な目標は、サービス層に影響を与えずに永続化テクノロジを変更できるようにすることではありません。たとえば、Hibernate から JPA に切り替えた場合は可能ですが、たとえば JPA から JDBC に切り替えた場合はそうではありません。その理由は
そのため、すべての永続化要素が DAO で分離されていたとしても、永続化テクノロジを変更すると、サービス層に影響が及びます。
このデカップリングの主な利点、私見は