Стоит ли перебирать коллекции в спящем режиме, чтобы найти объект или использовать критерии

Question

Что такое соглашение для этого? Скажем, например, у меня есть следующее, где ставка товара может быть ставкой только на один предмет:

public class Item {
    @OneToMany(mappedBy="item", nullable="false"
    Set<ItemBid> itemBids = new HashSet<ItemBid>()
}

Если мне дается имя участника торгов (которое хранится в ItemBid), если IA) Загрузите клуб, используя клубный дао, и перебирайте коллекцию его ItemBids, пока я не найду тот, с именем, которое хочу или B) Создайте dao ItemBid, в котором название клуба и наименование предмета используются в критериях или HQL.

Я бы предположил, что B) будет наиболее эффективным с очень большими коллекциями, поэтому будет ли это стандартным для извлечения очень специфических предметов из больших коллекций? Если да, могу ли я дать общее руководство относительно того, по каким причинам я должен использовать коллекции, и в какое время я должен использовать критерии / критерии DAO?

Answer 1

Да, вы должны определенно запрашивать ставки напрямую. Вот рекомендации:

• Если вы ищете конкретную ставку, используйте запрос
• Если вам нужно подмножество предложений, используйте запрос
• Если вы хотите отобразить все ставки для данного элемента - это зависит. Если количество предложений достаточно мало, возьмите предмет и используйте коллекцию. В противном случае - запрос напрямую.

Конечно, с точки зрения ОО, вы всегда должны использовать коллекцию (желательно иметь findBy*() методы в Item доступе к коллекции заявок внутри страны) - что также более удобно. Однако, если количество ставок на единицу является значительным, стоимость (даже ленивая) загрузки будет значительна, и вам скоро не хватит памяти. Этот подход также очень расточительный.

Answer 2

1. Вы должны задать себе этот вопрос гораздо раньше: к тому времени, когда вы делали отображение. Отображение для ORM должно быть интеллектуальной работой, а не копированием всех внешних ключей в атрибуты с обеих сторон. (хотя бы из-за ЯГНИ, но есть много других веских причин)

2. Скорее всего, сопоставление позиции ставки было бы лучше как однонаправленное (опять же, возможно, нет).

3. Во многих случаях мы обнаруживаем, что некоторые сущности тесно связаны с почти фиксированным числом некоторых других сущностей (их можно было бы назвать «агрегатами» на языке DDD). Например, счета и пункты счета. Или человек и список его увлечений. Или пост и набор тегов для этого поста. Мы не ожидаем, что количество товаров в данном счете будет расти со временем, равно как и количество тегов. Так что они все хорошие места для отображения @OneToMany. С другой стороны, число счетов для каждого клиента будет расти - поэтому мы просто сопоставим однонаправленный @ManyToOne с клиентом счет-фактуру - и запросим.

4. Репозитории (даос, что угодно), которые выполняют запросы, совершенно хороши в ОО (нет ничего плохого в запросе; это просто объект, описывающий ваши требования в нейтральной для хранения форме); использование искателей в сущностях - не так. С практической точки зрения он связывает ваши сущности с уровнем доступа к данным (DAO или даже классы JPA), и это сделает их непригодными для использования во многих случаях использования (GWT) или сложными для использования при отсоединении (вам придется угадывать, какие методы работают за пределами сессия). С философской точки зрения - это нарушает принцип единой ответственности и превращает ваши сущности JPA в своего рода активную запись подражателя.

Итак, мой ответ будет:

• если вам нужна одна ставка, запросите напрямую,
• если вы хотите отобразить все ставки для данного элемента - выберите элемент и используйте коллекцию. Это не зависит от количества ставок на элемент, поскольку запрос, выполняемый JPA, будет идентичен запросу, который вы можете выполнить самостоятельно. Если этот подход нуждается в настройке (как в случае, когда вам нужно выбрать много элементов и вы хотите избежать «проблемы выбора N + 1»), то есть множество способов (объединить выборку, получить выборку, подсказки), чтобы сделать это. правильно, без изменения части кода, которая использует getBids ().

Самый простой способ подумать об этом: если вы думаете, что какая-то коллекция никогда не будет отображаться с подкачкой страниц (например, теги на почте, элементы в счете, хобби на лице), сопоставьте ее с @OneToMany и получите доступ к коллекции.