ICollection<T> Vs List<T> in Entity Framework
I only watched a few webcasts before I went head first in to designing a few Entity Framework applications. I really didn't read that much documentation and I feel like I am suffering for it now.
I have been using List<T> in my classes, and it has worked great.
Now I have read some documentation and it states that I should have been using ICollection<T>. I changed to this, and it didn't even cause a model context change. Is this because both List<T> and ICollection<T> inherit IEnumerable<T>, and that is what is actually required for EF?
However, if this is the case, why doesn't the EF documentation state that it requires IEnumerable<T> instead of ICollection<T>?
In any case, are there any downsides to what I have done, or should I change it?
Solution 1:
Entity Framework would use ICollection<T> because it needs to support Add operations, which are not part of the IEnumerable<T> interface.
Also note that you were using ICollection<T>, you were merely exposing it as the List<T> implementation. List<T> brings along with it IList<T>, ICollection<T>, and IEnumerable<T>.
As for your change, exposing via the interface is a good choice, despite List<T> working. The interface defines the contract but not the implementation. The implementation could change. In some instances, perhaps the implementation could be a HashSet<T>, for example. (This is a mindset you could use for more than just Entity Framework, by the way. A good object-oriented practice is to program towards the interface and not the implementation. Implementations can and will change.)
Solution 2:
They picked the interface they did because it gives a comprehensible abstraction over the magic queries the Entity Framework performs when you use Linq.
Here's the difference between the interfaces:
-
IEnumerable<T>is read-only - You can add and remove items to an
ICollection<T> - You can do random access (by index) to a
List<T>
Out of those, ICollection and IEnumerable map well to database operations, since querying and adding/removing entities are things you might do in a DB.
Random access by index doesn't map as well, since you'd have to have an existing query result to iterate over, or each random access would query the database again. Also, what would the index map to? Row number? There aren't a lot of row number queries you'd want to do, and it isn't useful at all in building up bigger queries. So they simply don't support it.
ICollection<T> is supported, and will allow you to both query and change data, so use that.
The reason List<T> works to begin with is because the EF implementation ends up returning one in the end. But that's at the end of your query chain, not at the beginning. So making your properties ICollection<T> will make it more obvious that the EF creates a bunch of SQL and only returns a List<T> at the end, rather than doing queries for each level of Linq that you use.