2

他のフレームワークのクラス、列挙型などを使用するのは悪いことですか? JPAに基づくリポジトリにいくつかのファインダーメソッドがあり、フェッチタイプ(オブジェクトを遅延ロードするか熱心にロードするか)とFetchTypeJPAフレームワークの列挙型を目的に合わせて渡したいです。しかし、独自の列挙型/クラスを作成する方が良いでしょうか? アプリとフレームワークが結合されることは理解していますが、アプリはすでに JPA を使用しています。

4

4 に答える 4

2

あなた自身の質問に答えたようです。

... FetchTypeJPAフレームワークの列挙型は目的に適しています。

JPA がすでにアプリケーションの依存関係にあり、それらの型がユース ケースに適している場合、JPA 型の使用を避けるために車輪を再発明する必要はありません。

PS Gamb は、型の使用を永続化レイヤーに制限することを提案したとき、彼の答えで非常に良い点を指摘しています。

于 2012-11-11T18:35:27.237 に答える
2

確かに、FetchType列挙型を使用できますが、それをどこで使用しているかを検討してください。階層化された設計がある場合は、Persistence レイヤー以外のレイヤーでその列挙型を使用しないでください。そうしないと、上位レイヤーの JPA から参照をインポートする必要があります (必要な場合)。

EAGER別のアプローチ (としかないため) は、フィールドを取得する必要があるかどうかを定義し、その条件にフラグなどの値LAZYを割り当てることです。booleanlazyLoad

于 2012-11-11T18:41:21.793 に答える
1

robjb がすでに述べたように、一からやり直す必要はありません。これがフレームワークの全体的な目的です。開発者にツールとヘルパーを提供して、標準的なタスクを簡素化します。したがって、Framework-Classes を使用することをお勧めします。そして、それらがニーズに100％一致しない場合は、いつでもニーズに合わせて拡張できます-繰り返しますが、欠けているのが小さなネジだけである場合、ホイール全体を再発明する理由はありません:-P

于 2012-11-11T18:39:19.143 に答える
1

既にフレームワークを使用している場合でも、可能な限り、ロジックの上位層を解放したままにします。理由:

  • 誰かがあなたのコードを読んで、あなたがフレームワークからクラスを使用しているのを見ると、それがあなたのフレームワークとの通信に使用されていると想定します（わかりました、それは弱いです）。

  • 変更したい場合は、フレームワークのクラスのみを使用して対話する方が簡単です。

ただし、これは石で書かれたものではありません。自分でクラスを開発するのは時間のかかる投資である場合は、エンジンを変更したくない人がいないことを願って、それを選択することができます。

于 2012-11-11T18:41:42.580 に答える