Menu
In most of the NHiberate examples they use an ISET over an IList. I am aware of the basic differences between the two ie a set is unique. However, I am unsure why they use an ISet over an IList when doing lazy loading.
What advantage does (Iesi.Collections.Generic)ISet have over IList? Particularity when lazy loading.
873
ICollection<T> is an interface that exposes collection semantics such as Add() , Remove() , and Count . Collection<T> is a concrete implementation of the ICollection<T> interface. IList<T> is essentially an ICollection<T> with random order-based access.
You use IEnumerable when you want to loop through the items in a collection. IList is when you want to add, remove, and access the list contents out of order.
IList doesn't support further filtering. IEnumerable exists in System. Collections Namespace. IEnumerable is a forward only collection, it can't move backward and between the items.
ICollection is the most basic of the interfaces you listed. It's an enumerable interface that supports a Count and that's about it. IList is everything that ICollection is, but it also supports adding and removing items, retrieving items by index, etc.
I believe this is mostly due to NHibernate's java heritage.
See the FAQ entry on persistent collections. The specifically mention how Java contains more collections by default that C#, and they, in particular map to an ISet.
I believe the reason most samples use this is mainly just because this is more common in Java, and the samples were ported from Java. (Some of the samples use set without really needing it to be a set...)
That being said, there are distinct differences to a set vs. a list. The behavior is different, so there are use cases where a set's behavior is more appropriate. For lazy loading, this allows you to reduce the restriction on the order things are loaded, so you can potentially load less information and keep the interface contracts in place.
52
A set interface expresses only that the resulting collection can be:
a list interface expresses the first but the second is stronger, the ordering is well defined and will not change unless something instructs it to.
By using a less restrictive contract (set) you gain more freedom in what you can use (you may load the set in any order for example and no one using your class should care if this ordering is not consistent)
I have here glossed over the fact that the set further ensures than it cannot contain duplicates (which is a constrain on implementers). However if you needed to store such instances a set would simply be unacceptable so this ceases to be a problem in and instead becomes a positive. Consumer's work becomes even easier as they need not worry that duplicates exist at this has already been guaranteed for them.
40
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
