Створіть ідеальну сутність JPA [закрито]

Я працюю з JPA (реалізація в режимі глибокого сну) протягом деякого часу, і кожен раз, коли мені потрібно створювати об'єкти, я стикаюся з такими проблемами, як AccessType, незмінні властивості, equals / hashCode, ....
Тому я вирішив спробувати знайти загальну найкращу практику для кожного випуску і записати це для особистого використання.
Я б не заперечував проти того, щоб хтось прокоментував це чи сказав мені, де я помиляюся.

Клас сутності

• реалізувати Serializable

  Причина: Специфікація говорить про те, що потрібно, але деякі постачальники JPA цього не застосовують. Зимова сплячка як постачальник JPA цього не застосовує, але вона може вийти з ладу десь глибоко в шлунку за допомогою ClassCastException, якщо Serializable не буде впроваджено.

Конструктори

• створити конструктор з усіма необхідними полями сутності

  Причина: Конструктор повинен завжди залишати створений екземпляр у здоровому стані.

• крім цього конструктора: мати пакет приватного конструктора за замовчуванням

  Причина: конструктор за замовчуванням зобов’язаний Hibernate ініціалізувати об'єкт; приватне дозволено, але приватна (або загальнодоступна) видимість пакету потрібна для створення проксі-серверів виконання та ефективного пошуку даних без інструментарію байт-коду.

Поля / Властивості

• Використовуйте доступ до поля загалом та доступ до власності, коли це необхідно

  Причина: це, мабуть, найбільш дискусійне питання, оскільки немає чітких та переконливих аргументів для того чи іншого (доступ власності проти доступу до поля); однак, доступ до поля, здається, є загальним улюбленим через чіткіший код, кращу інкапсуляцію та відсутність необхідності створювати задачі для змінних полів

• Опустіть сеттери для змінних полів (не потрібно для поля типу доступу)

• властивості можуть бути приватними
  Причина: Я колись чув, що захищений краще для (Hibernate) продуктивності, але все, що я можу знайти в Інтернеті, це: Hibernate може отримати доступ до публічних, приватних та захищених методів доступу, а також до публічних, приватних та захищених полів безпосередньо . Вибір залежить від вас, і ви зможете зіставити його відповідно до дизайну програми.

Дорівнює / hashCode

• Ніколи не використовуйте згенерований ідентифікатор, якщо цей ідентифікатор встановлений лише при збереженні сутності
• За перевагою: використовуйте незмінні значення для формування унікального бізнес-ключа та використовуйте це для перевірки рівності
• якщо унікальний бізнес-ключ недоступний, використовуйте неперехідний UUID, який створюється під час ініціалізації об'єкта; Дивіться цю чудову статтю для отримання додаткової інформації.
• ніколи не посилайтеся на пов’язані особи (ManyToOne); якщо ця особа (як материнське підприємство) має бути частиною бізнес-ключа, то порівняйте лише ідентифікатори. Виклик 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

Я спробую відповісти на декілька ключових моментів: це на основі довгого сплячого / наполегливого досвіду, включаючи декілька основних програм.

Клас особи: реалізувати серіалізаційний?

Ключі потрібно реалізувати Serializable. Речі, які збираються перейти в HttpSession або надсилатись по протоколу RPC / Java EE, повинні реалізувати Serializable. Інші речі: не так багато. Витратьте свій час на те, що важливо.

Конструктори: створити конструктор з усіма необхідними полями сутності?

Конструктор (и) для логіки додатків повинен мати лише декілька критичних полів "зовнішній ключ" або "тип / вид", які завжди будуть відомі при створенні сутності. Решту слід встановити, зателефонувавши у методи сеттера - ось для чого вони і є.

Уникайте занадто багато полів в конструктори. Конструктори повинні бути зручними та надавати об’єкту основну розумність. Ім'я, тип та / або батьки зазвичай корисні.

OTOH, якщо правила заявки (сьогодні) вимагають від Замовника адреси, залиште її сетеві. Це приклад "слабкого правила". Можливо, на наступному тижні ви хочете створити об’єкт "Клієнт", перш ніж перейти на екран "Ввести деталі"? Не відмовляйтесь від себе, не залишайте можливості для невідомих, неповних або "частково введених" даних.

Конструктори: також пакет приватного конструктора за замовчуванням?

Так, але використовуйте "захищений", а не приватний пакет. Матеріали підкласифікації - це справжній біль, коли необхідні внутрішні місця не видно.

Поля / Властивості

Використовуйте доступ до поля "Властивості" для Hibernate та поза екземпляром. У межах примірника використовуйте поля безпосередньо. Причина: дозволяє працювати стандартне відображення, найпростіший та найосновніший метод для сплячки.

Що стосується полів, "непорушних" для програми - сплячий режим все ще повинен мати можливість їх завантажувати. Ви можете спробувати зробити ці методи приватними та / або поставити на них анотацію, щоб запобігти появі небажаного доступу до коду програми.

Примітка. Коли ви пишете функцію equals (), використовуйте getters для значень на іншому екземплярі! В іншому випадку ви потрапите на неініціалізовані / порожні поля на екземплярах проксі.

Чи захищений краще для (сплячої) продуктивності?

Навряд чи.

Дорівнює / HashCode?

Це стосується роботи з організаціями, перш ніж їх зберегти - що є тернистим питанням. Хешинг / порівняння за незмінними значеннями? У більшості бізнес-додатків таких немає.

Клієнт може змінити адресу, змінити назву своєї компанії тощо тощо - нечасто, але це буває. Виправлення також потрібно робити, коли дані були введені неправильно.

Кілька речей, які, як правило, зберігаються незмінними, це Parenting і, можливо, Type / Kind - звичайно користувач відтворює записи, а не змінює їх. Але вони не однозначно ідентифікують сутність!

Отже, довго і коротко, заявлені "незмінні" дані насправді не є. Поля первинного ключа / ідентифікатора створюються з точною метою, щоб забезпечити таку гарантовану стабільність та незмінність.

Вам потрібно спланувати та врахувати свою потребу в порівнянні та хешировании та обробці запитів на робочих фазах, коли A) робота зі "зміненими / прив'язаними даними" з інтерфейсу користувача, якщо ви порівнюєте / хеш на "нечасто змінених полях" або B), що працюють з " незбережені дані ", якщо ви порівнюєте / хеш по ID.

Equals / HashCode - якщо унікальний бізнес-ключ недоступний, використовуйте неперехідний UUID, який створюється при ініціалізації сутності

Так, це хороша стратегія, коли потрібно. Майте на увазі, що UUID не є безкоштовними, хоча вони залежать від продуктивності - і кластеризація ускладнює справи.

Рівно / HashCode - ніколи не посилайтеся на пов'язані сутності

"Якщо пов’язана особа (як батьківська особа) повинна бути частиною бізнес-ключа, тоді додайте поле, яке не можна вставити, не можна оновити, щоб зберігати батьківський ідентифікатор (з тим самим іменем, як ManytoOne JoinColumn), і використовувати цей ідентифікатор для перевірки рівності "

Звучить як хороша порада.

Сподіваюся, це допомагає!

У специфікації JPA 2.0 зазначено, що:

• Клас особи повинен мати конструктор без аргументів. У нього можуть бути й інші конструктори. Конструктор без аргументів повинен бути відкритим або захищеним.
• Клас сутності повинен бути класом вищого рівня. Перерахунок або інтерфейс не повинні позначатися як сутність.
• Клас сутності не повинен бути остаточним. Жодні методи чи стійкі змінні екземплярів класу сутності не можуть бути остаточними.
• Якщо екземпляр об'єкта повинен передаватися за значенням як відокремлений об'єкт (наприклад, через віддалений інтерфейс), клас сутності повинен реалізувати інтерфейс Serializable.
• Як абстрактні, так і конкретні класи можуть бути сутностями. Суб'єкти можуть розширювати не-сутнісні класи, а також класи сут.

Специфікація не містить жодних вимог щодо реалізації методів рівних та хеш-кодів для сутностей, лише для класів первинних ключів та ключів карти, наскільки я знаю.

Мої 2 копійки додаються до відповідей тут:

1. З посиланням на доступ до поля чи власності (осторонь міркувань щодо продуктивності) обидва мають законний доступ за допомогою геттерів та сетерів, тому моя логіка моделі може встановлювати / отримувати їх однаково. Різниця виникає тоді, коли постачальнику постійної тривалості (Hibernate, EclipseLink або іншому) потрібно зберегти / встановити деякий запис у Таблиці A, який містить зовнішній ключ, що посилається на якийсь стовпець у Таблиці B. У випадку типу доступу до власності, збереження система виконання використовує метод кодованого сеттера, щоб призначити комірці в стовпці таблиці нового значення. У випадку типу доступу до поля система виконання постійної тривалості встановлює комірку в стовпці таблиці B безпосередньо. Ця різниця не має важливого значення в контексті однонаправлених відносин, однак ОБОВ'ЯЗКОВО використовувати власний кодований метод сеттера (тип доступу до властивості) для двонаправлених відносин за умови, що метод сеттера добре розроблений для обліку узгодженості. Послідовність є критичним питанням для двонаправлених відносин, які стосуються цьогопосилання на простий приклад для добре розробленого сеттера.

2. З посиланням на Equals / hashCode: Неможливо використовувати автоматично створені Eclipse методи Equals / hashCode для суб'єктів, що беруть участь у двонаправленому співвідношенні, інакше вони матимуть циркулярну посилання, що призводить до виключення stackoverflow. Як тільки ви спробуєте двонаправлене відношення (скажімо, OneToOne) і автоматично генерує рівне () або hashCode () або навіть toString (), ви потрапите в цей виняток stackoverflow.

Інтерфейс сутності

public interface Entity<I> extends Serializable {

/**
 * @return entity identity
 */
I getId();

/**
 * @return HashCode of entity identity
 */
int identityHashCode();

/**
 * @param other
 *            Other entity
 * @return true if identities of entities are equal
 */
boolean identityEquals(Entity<?> other);
}

Основна реалізація для всіх об'єктів, спрощує реалізацію рівних / хеш-кодів:

public abstract class AbstractEntity<I> implements Entity<I> {

@Override
public final boolean identityEquals(Entity<?> other) {
    if (getId() == null) {
        return false;
    }
    return getId().equals(other.getId());
}

@Override
public final int identityHashCode() {
    return new HashCodeBuilder().append(this.getId()).toHashCode();
}

@Override
public final int hashCode() {
    return identityHashCode();
}

@Override
public final boolean equals(final Object o) {
    if (this == o) {
        return true;
    }
    if ((o == null) || (getClass() != o.getClass())) {
        return false;
    }

    return identityEquals((Entity<?>) o);
}

@Override
public String toString() {
    return getClass().getSimpleName() + ": " + identity();
    // OR 
    // return ReflectionToStringBuilder.reflectionToString(this, ToStringStyle.MULTI_LINE_STYLE);
}
}

Номер особи імпл:

@Entity
@Table(name = "ROOM")
public class Room extends AbstractEntity<Integer> {

private static final long serialVersionUID = 1L;

@Id
@GeneratedValue(strategy = GenerationType.AUTO)
@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;
}

public Integer getId(){
    return id;
}

public Building getBuilding() {
    return building;
}

public String getNumber() {
    return number;
}


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

//no setters for number, building nor id
}

Я не бачу сенсу порівнювати рівність суб'єктів, що базуються на галузях бізнесу, у кожному випадку суб'єктів JPA. Це може бути більше випадком, якщо ці об'єкти JPA розглядаються як ValueObjects, керовані доменом, а не суб'єктами, керованими доменом (для яких ці приклади коду).