Какой тип Java вы используете для коллекций JPA и почему?

Какой из следующих типов коллекций вы используете в своей модели домена JPA и почему:

java.util.Collection
java.util.List
java.util.Set

Мне было интересно, существуют ли для этого некоторые основные правила.

UPDATE Я знаю разницу между Set и List. A List позволяет дублировать и имеет порядок, а Set не может содержать повторяющиеся элементы и не определяет порядок. Я задаю этот вопрос в контексте JPA. Если вы строго следуете определению, то вы всегда должны использовать тип Set, поскольку ваша коллекция хранится в реляционной базе данных, где вы не можете иметь дубликаты и где вы сами определяете заказ, то есть порядок в вы Java List не обязательно сохраняются в БД.

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

Ответ 1

Как и ваш собственный вопрос, ключ - это домен, а не JPA. JPA - это всего лишь фреймворк, который вы можете (и должны) использовать таким образом, который наилучшим образом соответствует вашей проблеме. Выбор субоптимального решения из-за рамки (или его пределов) обычно является предупреждающим звонком.

Когда мне нужен набор и никогда не заботятся о порядке, я использую Set. Когда по какой-то причине порядок важен (упорядоченный список, упорядочение по дате и т.д.), Тогда List.

Вам, кажется, хорошо известно различие между Collection, Set и List. Единственная причина использовать один против другого зависит только от ваших потребностей. Вы можете использовать их, чтобы сообщать пользователям вашего API (или вашего будущего) свойства вашей коллекции (что может быть тонким или неявным).

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

Например, когда я вижу a List, я знаю, что он сортируется каким-то образом, и что дубликаты являются приемлемыми или несущественными для этого случая. Когда я вижу Set, я обычно ожидаю, что он не будет иметь дубликатов и не будет иметь определенного порядка (если это не SortedSet). Когда я вижу a Collection, я не ожидаю от него ничего большего, чем содержать некоторые объекты.

Что касается заказа списка... Да, его можно сохранить. И даже если это не так, и вы просто используете @OrderBy, это все равно может быть полезно. Подумайте о примере журнала событий, отсортированном по метке времени по умолчанию. Искусственное переупорядочение списка маловероятно, но все же может оказаться полезным, что он сортируется по умолчанию.

Ответ 2

Вопрос об использовании набора или списка гораздо сложнее, я думаю. По крайней мере, когда вы используете hibernate как реализацию JPA. Если вы используете Список в спящем режиме, он автоматически переключается на парадигму "Сумки" , где существуют дубликаты CAN.

И это решение оказывает существенное влияние на запросы, выполняемые спящим режимом. Вот небольшой пример:

Есть два объекта: сотрудник и компания, типичное отношение "многие ко многим". для сопоставления этих сущностей друг с другом существует JoinTable (позволяет называть его "employeeCompany" ).

Вы выбираете Список типов данных для обоих объектов (Company/Employee)

Итак, если теперь вы решите удалить Employee Joe из CompanyXY, hibernate выполнит следующие запросы:

delete from employeeCompany where employeeId = Joe;
insert into employeeCompany(employeeId,companyId) values (Joe,CompanyXA);
insert into employeeCompany(employeeId,companyId) values (Joe,CompanyXB);
insert into employeeCompany(employeeId,companyId) values (Joe,CompanyXC);
insert into employeeCompany(employeeId,companyId) values (Joe,CompanyXD);
insert into employeeCompany(employeeId,companyId) values (Joe,CompanyXE);

И теперь вопрос: почему, черт возьми, hibernate не только выполняет этот запрос?

delete from employeeCompany where employeeId = Joe AND company = companyXY;

Ответ прост (и много для Нирава Ассара для его блога): Он не может. В мире мешков удалить все и повторно вставить все остальное - это единственный правильный способ! Прочтите это для более подробных разъяснений. http://assarconsulting.blogspot.fr/2009/08/why-hibernate-does-delete-all-then-re.html

Теперь большой вывод:

Если вы выбираете Set вместо List в своих Employee/Company-Entities, у вас нет этой проблемы, и выполняется только один запрос!

И почему? Поскольку hibernate больше не находится в мире сумок (как вы знаете, Sets не допускает дубликатов), и теперь возможен только один запрос.

Таким образом, решение между List и Sets не так просто, по крайней мере, когда дело доходит до запросов и производительности!

Ответ 3

Обычно я использую List. Я считаю API List более полезным и совместимым с другими библиотеками, чем Set. Список проще итерации и, как правило, более эффективен для большинства операций и памяти.

Тот факт, что отношения не могут иметь дубликаты и обычно не упорядочен, не должен требовать использования набора, вы можете использовать любой тип коллекции, наиболее полезный для вашего приложения.

Это зависит от вашей модели, хотя, если это то, что вы собираетесь делать много, содержит проверки, тогда Set будет более эффективным.

Вы можете заказать отношения в JPA, используя @OrderBy или @OrderColumn.

См, http://en.wikibooks.org/wiki/Java_Persistence/Relationships#Ordering

Дубликации обычно не поддерживаются в JPA, но некоторые сопоставления, такие как ElementCollections, могут поддерживать дубликаты.

Ответ 4

Я использую:

Установить: когда элементы в коллекциях не имеют порядка и являются уникальными
Список: когда у товаров есть заказ

Ответ 5

Я думаю, что использование Collection в качестве стандартного дефолта при создании объектов с Netbeans является хорошей отправной точкой, тогда, когда вы выясните, что такое ваша модель на самом деле, и вам нужно больше функциональности, вы можете легко изменить ее и оставаться обратно совместимой.