JPA Ненужный класс User внутри класса Transaction - PullRequest
0 голосов
/ 25 апреля 2020

Класс пользователя

@Entity
class User {
    @OneToMany
    List<Order> orders;
}

Класс заказа

@Entity
class Order {   
    @ManyToOne
    User user;

    @OneToOne
    Transaction transaction 
}

Класс транзакции

@Entity
class Transaction {
    @OneToOne
    Order order;

    @ManyToOne
    User user; // Do you think this is necessary?

    void makeTransaction(long orderId){
        //Here I can easily get user object using orderId, right?
    }
}

Я очень новичок в Hibernate. В моем проекте я не понимаю, почему пользовательский атрибут User был добавлен в класс Transaction, когда я каким-то образом собираюсь получить объект User через объект Order.

Итак, неужели выше дизайн класса Transaction неправильный? или это будет создавать какие-либо проблемы позже?

1 Ответ

2 голосов
/ 28 апреля 2020

Это зависит от ваших бизнес-требований и потребностей бизнеса.

На первый взгляд он кажется полностью избыточным (с обеих сторон, база данных (избыточный банк FK) и сторона OO (избыточная ссылка).

Но здесь ничто не говорит мне, что пользователь в заказе и пользователь в транзакции на самом деле одно и то же ...

Как вы объясняете, это "кажется" одинаковым, но лично я не знаю. Так что, если оба пользователя могут быть "разными", эта модель работает.

Теперь, если мы предположим, что пользователь всегда одинаков в обеих концепциях, и у вас есть такой вариант использования: load transactions by some criteria (timestamp, priority, whatever) "owns" by a specific user Без какой-либо "пользовательской" информации в транзакции вы должны l oop просмотреть все его заказы и отфильтровать / восстановить транзакции, которые вы нужно. С пользовательской информацией внутри вы можете напрямую добраться до таблицы транзакций (и вы даже можете избежать быстрой загрузки Order или просто использования проекции DTO).

Теперь возможно вместо сохранения hard reference во User Вы можете просто сохранить ссылку на него: private Long userId и таким образом уменьшить риск возникновения циклических c зависимостей.

Имейте это в виду -> ll избыточность.

В реляционном моделировании избыточность возникает, когда вы применяете некоторую денормализацию к вашей модели, а иногда это просто необходимо (с точки зрения производительности, необходимости варианта использования, потребности проекции ...).

Если вы в сознании и согласны с этим, это нормально. Просто позаботьтесь о Consistency проблеме, которая может возникнуть, и будьте готовы обработать это свойство.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...