私はHibernateにかなり慣れていません。これらの単純なロジックを理解するのに問題があります。@Repository が Spring によってオブジェクトにアクセスするために使用されることを理解しました。また、Hibernate は @Entity を使用して、データベース テーブルにマップされるエンティティを示します。@Repository と @Entity の両方が多かれ少なかれ同じことを意味するため、単一のクラスに注釈を付けることができるかどうか疑問に思っていました。
2 に答える
それらはまったく同じことを意味するものではありません。
@実在物
@Entity は、ビジネス ドメイン内の「もの」を表すものです。顧客、象、製品など、何でもかまいません。. . データベースに永続化される属性と、それらの属性に関連するメソッドがあります (貧血のエンティティでない限り、少なくともそうあるべきですが、それはアンチパターンです. . . 後で、基本は、Spring の @Configurable アノテーションを確認してください - これにより、エンティティにコラボレーターを提供できます)。
@リポジトリ
一方、@Repository は、これらのエンティティを取得および格納するためのインターフェイスを提供します。
特に他の言語では、永続性とエンティティ属性を同じオブジェクトに結合するフレームワークがいくつかありますが、これは Java/Hibernate/Spring では一般的ではありません。
番号。
Hibernate エンティティは Hibernate ORM フレームワークによって管理され、get() または load() 経由でアクセスすると、hibernate によってエンティティ (およびそのプロキシ) が作成されます。それらは、Spring Bean とは完全に異なる (そして複雑な) ライフサイクルを持っています (それらは、アタッチ/デタッチ/プロキシ/削除待ちの可能性があります)。
Spring リポジトリは、Spring フレームワークによって管理されるシングルトンです。通常、それらはコンテナー インスタンスが存在する限り存在します。新しい Hibernate セッションが開かれたり閉じられたり、新しいユーザー セッションが有効になったり、有効期限が切れたりすることがありますが、リポジトリの同じシングルトン インスタンスが引き続き存在します。
Hibernate オブジェクトの可能な状態については、http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/objectstate.html#objectstate-overviewを参照してください。
リポジトリ インスタンスについては、サービスであるため、通常はステートレスです。
RE:they more or less imply the same.
いいえ、それらは同じではありません。古い冗談があった
電球を交換するのに何人の C++ プログラマーが必要ですか? あなたはまだ手続き的に考えています。適切に設計された電球オブジェクトは、一般的な電球クラスから変更メソッドを継承するため、電球変更メッセージを送信するだけで済みます。
しかし、優れた OOP プログラマーはそのようには考えていません。単一責任の原則によれば、オブジェクトには変更する理由が 1 つあるはずです。リポジトリはインフラストラクチャで動作し、ビジネス ルールとは関係ありません。インフラストラクチャは変更される可能性があります (たとえば、オブジェクトを RDBMS ではなく XML に格納する必要がある場合があります) が、ビジネス オブジェクトの状態をカプセル化するクラスには影響しません。
エンティティ クラスから抽象リポジトリ インターフェイスへの参照を作成することで、この問題を軽減できる可能性があります (悪名高いActive Recordパターンを実装します。これは、電球から抽象的な電球ソケットを参照するようなものです。これは良い解決策ではないようです。電球ソケットと電球ではライフサイクルが異なります)。
ここで、高結束の原則が機能し始めます。これによると、モデルからの抽象化を反映する役割を持つオブジェクトが、持続性やネットワーク経由での送信など、まったく関係のないことを実行することは非論理的です。Student
クラスがprint()
、saveToXml()
またはtransmitByHttp()
メソッドを持つのは奇妙です。