This question already has answers here:
IList vs IEnumerable for Collections on Entities
(2 answers)
Closed 9 years ago.
Can anyone tell me when I should use either.
For example, I think I should use an IList when I want to access the .Count of the collection or an individual item, correct?
Thank you.
Generally speaking, you should try and use the least specific type that suits your purpose. IEnumerable is less specific than IList (IList implements IEnumerable) so unless you want something specific from IList (such as Count as you suggest, or perhaps Add, Delete, etc), I'd use IEnumerable.
One benefit of remaining with IEnumerable is that you can write iterator methods to return this type (look up "yield return" and iterator methods if you are not familiar with them). This allows you to write very memory efficient "pipelines" for your loops.
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 vs IEnumerable for Collections on Entities
http://www.informit.com/guides/content.aspx?g=dotnet&seqNum=722
You should use IList when you need access by index to your collection, add and delete elements, etc., and IEnumerable when you need just enumerate over your collection.
A very simple answer, I can extend it if you will describe you scenario.
Related
This question already has answers here:
Can anyone explain IEnumerable and IEnumerator to me? [closed]
(16 answers)
Closed 7 days ago.
I want to know the exact place where we should use IEnumberable<T>
I know how IEnumerable<T> work and returns IEnumerator<T> and all that but the ultimate goal of IEnumerable<T> is to query the data from the collection isn't it? That is what we can already do using foreach() loop ? So when to use IEnumerable<T>? what is the actual practical scenario where the IEnumerable<T> is the only option to query the collection?
but the ultimate goal of IEnumerable<T> is to query the data from the collection isn't it?
No; the goal of IEnumerable<T> is to provide access to a sequence, which may or may not be a collection. The point being to abstract away what the underlying source is. It could be a raw collection, but it could be:
some LINQ (or similar) projection (collection.Where(...).Select(...) etc)
an open query to ADO.NET, redis, a socket, gRPC, a file or some other data provider that isn't readily countable, repeatable, etc - just: "a sequence"
an in-process data generator
some producer/consumer setup
etc
If you know you're always iterating a collection, then sure: feel free to use the concrete type, or ICollection<T>/IList<T> etc; but: not every sequence is a collection.
This question already has answers here:
List<T> or IList<T> [closed]
(18 answers)
Closed 8 years ago.
Why here interface Ilist is used to create an object of List type
IList<BankAccountView> bankAccountViews = new List<BankAccountView>();
when it can be done like this
List<BankAccountView> bankAccountViews = new List<BankAccountView>();
A List is a concrete type, while an IList is a contract for which you can use any implemtation that an IList has.
An IList has a set of methods as defined on MSDN: http://msdn.microsoft.com/en-us/library/system.collections.ilist.aspx
Here's a very good blogpost explaining it in detail: http://www.claudiobernasconi.ch/2013/07/22/when-to-use-ienumerable-icollection-ilist-and-list/
So when writing a function or method that takes a collection, write it not to take a List, but an IList, an ICollection, or IEnumerable. The generic interfaces will still work even for heterogenous lists because System.Object can be a T too. Doing this will save you headache if you decide to use a Stack or some other data structure further down the road. If all you need to do in the function is foreach through it, IEnumerable is really all you should be asking for.
On the other hand, when returning an object out of a function, you want to give the user the richest possible set of operations without them having to cast around. So in that case, if it's a List internally, return a copy as a List.
Read link: When to use IList and when to use List
This question already has answers here:
When to use IList and when to use List
(12 answers)
Closed 9 years ago.
I saw a function like
public FuncA(string param1, IList<SqlParameter> sqlParamsList)
I wonder why the author was using IList instead of List? Which one is better? I know the difference between them is one is interface, the other one is class. So my final question is when to use which?
More than one class can implement the IList interface. If you use IList you accept any class that implements IList.
If you use List, you can only pass List and derived classes.
Using an interface is generally preferable as it makes the API more flexible for the caller. If your method accepts the interface rather than the concrete implementation, the caller can use whatever type they want (List, Array, ImmutableList...), as long as it implements IList.
Using an interface is preferred over a concrete type in order to allow a caller to pass in any object that implements the interface.
Especially in public methods this is good practice.
I would tend towards using the IList interface parameter over the concrete implementation, unless there was some reason you absolutely HAD to have the concrete List parameter.
By using IList instead of List, your method can now accept all collection types that implement IList, which may or may not be a collection that directly inherits from List. List and any of its subclasses implement IList as well, so they would also be included in the set of available types your method could use. Using IList in this case allows you to be more flexible.
Also, in unit testing scenarios, IList may be easier to mock out, depending on what exactly you're trying to test and what your features your mocking framework has.
This question already has answers here:
How to tell if an IEnumerable<T> is subject to deferred execution?
(6 answers)
Closed 9 years ago.
I have a Cache wrapper class that I use, which provides type safety and segmenting and other nice things.
I want to make it prevent me from shooting myself in the foot by caching an un-materialized LINQ query and only accept lists/collections...
Is there a way to detect if an IEnumerable is a LINQ query?
Maybe I'm answering my own question and should throw an exception when T is IEnumerable but not ICollection.
I would suggest just wrapping the IEnumerable<T> within your own collection, "materializing" it yourself.
This will provide full safety and more consistency, at the expense of potentially generating another collection instance and copying the references over.
You could always do a check for ICollection<T> and not regenerate, or similar, but there are still advantages to copying the contents into your own list. One major one is that you then control the one and only instance of the collection - you don't have to worry about another object adding or removing items (which may or may not be an issue, but is likely problematic for segmenting).
This question already has answers here:
Closed 11 years ago.
Possible Duplicates:
IList<int> vs List<int>
C# - List<T> or IList<T>
What is the difference between List and IList, which one has better performance and when to use List over IList and vice versa?
In C# List is a concrete implementation of the IList interface. The List is an implementation of the IList Interface. The idea is to program against the interface, not the implementation. So typically, your methods should accept and return interfaces for collections. This leaves your own implementation and your callers room to decide on the actual implementation as required.
Benefit of using an Interface is that you get to implement your functionality or better yet, the only functionality you require. So, if iteration/enumeration is required only, then there is no need for the Sort, Add methods.
List implements IList interface
IList is a interface and doesn't have any implementation, so the performance of IList depending the class it implements
IList is the interface - see this question for more information - List<T> or IList<T>