NHibernate ISet Vs IList

Ответ 1

Я считаю, что это в основном связано с наследием NHibernate java.

Смотрите часто задаваемые вопросы о постоянных коллекциях. В частности, упоминается, что Java содержит больше коллекций по умолчанию, которые С#, и они, в частности, сопоставляются с ISet.

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

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

Ответ 2

Установленный интерфейс выражает только то, что полученный набор может быть:

• проверено на членство
• перечислил в некотором произвольном порядке (который может измениться)

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

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

Я здесь замалчиваю тот факт, что набор далее гарантирует, что он не может содержать дубликаты (что является ограничителем для исполнителей). Однако, если вам нужно было хранить такие экземпляры, набор был бы просто неприемлем, так что это перестает быть проблемой и вместо этого становится положительным. Потребительская работа становится еще проще, так как им не нужно беспокоиться о том, что дубликаты существуют в этом уже гарантированы для них.