java - アノテーション - jpa 継承マッピング

完全なJPAエンティティを作成する (3)

私はJPA（Hibernateの実装）を使っていましたが、エンティティを作成する必要があるたびに、AccessType、不変プロパティ、equals / hashCodeなどの問題に苦しんでいます。
そこで私は、各問題の一般的なベストプラクティスを見つけ出し、個人的な使用のためにこれを書き留めることに決めました。
私はそれについて誰かがコメントしたり、どこに間違っているか教えてもらえません。

エンティティクラス

• Serializableを実装する

  理由： 仕様には必要があると言われていますが、一部のJPAプロバイダはこれを強制しません。 JPAプロバイダとしてのHibernateはこれを強制しませんが、Serializableが実装されていない場合、ClassCastExceptionを使用して胃のどこかで失敗する可能性があります。

コンストラクタ

• エンティティのすべての必須フィールドを含むコンストラクタを作成する

  理由：コンストラクタは、作成されたインスタンスを常に元の状態のままにしておく必要があります。

• このコンストラクタの他に、パッケージをプライベートなデフォルトのコンストラクタにする

  理由：デフォルトのコンストラクタは、Hibernateにエンティティを初期化させる必要があります。 非公開は許可されていますが、実行時プロキシの生成とバイトコード計測なしの効率的なデータ取得には、パッケージのプライベート（またはパブリック）可視性が必要です。

フィールド/プロパティ

• 必要に応じて、一般的なフィールドアクセスとプロパティアクセスを使用する

  理由：これはおそらく最も議論の余地がある問題です。なぜなら、どちらか一方のための明確で説得力のある議論がないからです（プロパティアクセスとフィールドアクセス）。 しかし、コードが明確になり、カプセル化が改善され、不変フィールド用のセッターを作成する必要がないため、フィールドアクセスは一般的に好まれるようです

• 不変フィールドのセッターを省略する（アクセスタイプフィールドには不要）

• プロパティは非公開にすることができる
  理由：私は一度、protected（Hibernate）のパフォーマンスが良いと聞きましたが、Web上で見つけることができるのは、 Hibernateはpublic、private、protectedのアクセサメソッド、およびpublic、private、protectedフィールドに直接アクセスできます。 選択肢はあなた次第です。アプリケーション設計に合わせて調整することができます。

等しい/ハッシュコード

• このIDがエンティティを永続化するときにのみ設定される場合は、生成されたIDを使用しないでください
• 優先度：不変の値を使用して一意のビジネスキーを形成し、これを使用して等価性をテストする
• 一意のビジネスキーが利用できない場合は、エンティティが初期化されたときに作成される非一時的なUUIDを使用します。 詳細については、 この素晴らしい記事を参照してください。
• 関連するエンティティを参照することはありません （ManyToOne）。 このエンティティ（親エンティティのような）がビジネスキーの一部である必要がある場合は、IDのみを比較します。 プロキシでgetId（）を呼び出すと、 プロパティアクセスタイプを使用している限り、エンティティの読み込みがトリガーされません。

エンティティの例

@Entity
@Table(name = "ROOM")
public class Room implements Serializable {

    private static final long serialVersionUID = 1L;

    @Id
    @GeneratedValue
    @Column(name = "room_id")
    private Integer id;

    @Column(name = "number") 
    private String number; //immutable

    @Column(name = "capacity")
    private Integer capacity;

    @ManyToOne(fetch = FetchType.LAZY, optional = false)
    @JoinColumn(name = "building_id")
    private Building building; //immutable

    Room() {
        // default constructor
    }

    public Room(Building building, String number) {
        // constructor with required field
        notNull(building, "Method called with null parameter (application)");
        notNull(number, "Method called with null parameter (name)");

        this.building = building;
        this.number = number;
    }

    @Override
    public boolean equals(final Object otherObj) {
        if ((otherObj == null) || !(otherObj instanceof Room)) {
            return false;
        }
        // a room can be uniquely identified by it's number and the building it belongs to; normally I would use a UUID in any case but this is just to illustrate the usage of getId()
        final Room other = (Room) otherObj;
        return new EqualsBuilder().append(getNumber(), other.getNumber())
                .append(getBuilding().getId(), other.getBuilding().getId())
                .isEquals();
        //this assumes that Building.id is annotated with @Access(value = AccessType.PROPERTY) 
    }

    public Building getBuilding() {
        return building;
    }


    public Integer getId() {
        return id;
    }

    public String getNumber() {
        return number;
    }

    @Override
    public int hashCode() {
        return new HashCodeBuilder().append(getNumber()).append(getBuilding().getId()).toHashCode();
    }

    public void setCapacity(Integer capacity) {
        this.capacity = capacity;
    }

    //no setters for number, building nor id

}

このリストに追加するその他の提案は、歓迎以上のものです...

更新

この記事を読んで以来、私はeq / hCを実装する私の方法を適応させました。

• 不変の単純なビジネスキーが利用可能な場合：その
• 他のすべての場合：uuidを使用する