4

（たとえば）自動的に生成された長いIDを持つJPAエンティティを想定します。

@Entity
@AutoProperty
public class SomeItem {

    @Id
    @GeneratedValue(strategy=GenerationType.AUTO)   
    private long Id;

    ...

}

このIDのセッターとゲッターを生成しない理由はありますか？IDを生成するのはJPAの責任であるため、たとえば、セッターを生成しないように誘惑される可能性があります。

4

3 に答える 3

21

他のコメントがあなたを誤解させているように思われるので、科学的で完全な答えをあなたに与えることはできませんが、私はこの問題について少し詳しく説明する義務があると感じています。@vcetinickは現在受け入れられている答えを書きました：

あなたは物事の永続性の側面から[..]逃げることができるかもしれないことに気付くかもしれません。

特にこの引用は間違っています。すべては、@Id注釈を配置する場所によって異なります。仕様によると：

エンティティがフィールドベースのアクセス権を持っている場合、永続性プロバイダーのランタイムはインスタンス変数に直接アクセスします。

したがって、セッターまたはゲッターを提供する必要はありません。ゲッターメソッドではなくフィールドに注釈を付けたためです（セッターメソッドへの注釈は無視され、関係がありません）。

ただし、getterメソッドを記述し、フィールドの代わりに@Idアノテーションを付けてこのメソッドに注釈を付けた場合、永続性プロバイダーに、アクセサー（getter ）メソッドとミューテーター（setter）メソッドを介してフィールドにアクセスし、リフレクションを使用しないように指示します。 。その場合、ゲッターとセッターの両方が存在する必要があります。本ProJPA2：MasteringtheJava™PersistenceAPIは、71ページに書いています（私による太字のマークアップ！）：

プロパティアクセスモードを使用する場合、JavaBeansの場合と同じコントラクトが適用され、永続プロパティにはgetterメソッドとsetterメソッドが必要です。プロパティのタイプは、getterメソッドの戻りタイプによって決定され、setterメソッドに渡される単一のパラメーターのタイプと同じである必要があります。どちらの方法も、パブリックまたは保護された可視性である必要があります。

したがって、私は通常、idフィールドに注釈を付け、setterメソッドとgetterメソッドの両方を記述しますが、setterメソッドは保護されたアクセスを提供します。他のコードに、このような重要なフィールドへの簡単な書き込みアクセス権を持たせたくありません。これが他のドメインで問題を引き起こすかどうかはわかりません。私は専門家ではありません。しかし、この方法でid属性を設定しない理由についても理由が​​わかりません。Netbeansフォーラムも参照してください。

于 2013-02-16T20:17:35.703 に答える
6

永続性の側面からJPAエンティティにゲッター/セッターを配置しなくても逃げることができる場合があります。ただし、他のソースからシリアル化されたエンティティの処理を開始する場合、場合によってはビューからでも、エンティティのIDを設定して、既存のエンティティを処理していることをJPAに通知する方法が必要になります。 IDを設定すると、永続レイヤーはそれを新しいオブジェクトとして扱います。

于 2012-09-11T12:48:40.040 に答える
2

Idこれがないと、データベースにレコードを挿入できなくなります。あなたの場合 、それはそれぞれに対して生成される@GeneratedValue(strategy=GenerationType.AUTO)ことを保証しますが、それはあなたの主要な識別であるため、それにアクセスするためのメソッドが必要になります。idpersistentity

それはあなたが誰かに彼の名前を尋ねるようなもので、彼はあなたにそれを提供しません、そしてあなたは彼がただ失礼であると思うでしょう。

于 2012-09-11T12:37:01.707 に答える