В большинстве примеров NHiberate они используют ISET над IList. Я знаю основные различия между ними, т.е. набор уникален. Тем не менее, я не уверен, почему они используют ISet над IList при ленивой загрузке.
В чем преимущество (Iesi.Collections.Generic) ISet над IList? Особенность при ленивой загрузке.
Я считаю, что это в основном связано с наследием NHibernate java.
Смотрите часто задаваемые вопросы о постоянных коллекциях. В частности, упоминается, что Java содержит больше коллекций по умолчанию, которые С#, и они, в частности, сопоставляются с ISet.
Я считаю, что большинство примеров использует это, главным образом, потому, что это более распространено в Java, а образцы были перенесены с Java. (Некоторые из образцов используют набор, не требуя, чтобы он был набором...)
Говоря, существуют разные отличия от набора против списка. Поведение отличается, поэтому существуют случаи, когда поведение набора более уместно. Для ленивой загрузки это позволяет уменьшить ограничение на порядок вещей, поэтому вы можете загрузить меньше информации и сохранить контракты интерфейса на месте.
Установленный интерфейс выражает только то, что полученный набор может быть:
интерфейс списка выражает первый, а второй сильнее, порядок хорошо определен и не изменится, если что-то его не инструктирует.
Используя менее ограничительный контракт (набор), вы получаете больше свободы в том, что вы можете использовать (вы можете загрузить набор в любом порядке, например, и никто, кто использует ваш класс, не должен заботиться, если это упорядочение не соответствует)
Я здесь замалчиваю тот факт, что набор далее гарантирует, что он не может содержать дубликаты (что является ограничителем для исполнителей). Однако, если вам нужно было хранить такие экземпляры, набор был бы просто неприемлем, так что это перестает быть проблемой и вместо этого становится положительным. Потребительская работа становится еще проще, так как им не нужно беспокоиться о том, что дубликаты существуют в этом уже гарантированы для них.