Little missleading explanation. IEnumerable is just an interface that gives you iterator. You decribing EF implemantation. For example to get 10th element from IEnumerable you cannot just get it by adress - arr[9]. You need to itereate by every element - one by one, as a seqeance . This gives flexibility for diffrent implementations because that way data structure that is impelementing IEnumerable can optimize memory consumption and fetch only one element at the time. If you are have 1000 element list but you want to read only first, all elements of the List will be loaded to the memory (such a waste) . If you use IEnumerable it should load only one - when accessed. Entity Framework implements IEnumebrable(iQuerable). If you call "toList" It will load all selected record from database to the memory (because you need to have all data to create a list). if you don't call "to List" and just itereate EF will load one element at the time (creating many select querries to the database).
His explanation was on point, and not "dependent on EF implementation". IEnumerables are really lazy , they describe an interface for iteration and they return an IEnumerator that is iterated one element at a time (it does not matter how the underlying implementation works, it is made to serve only when iterated, thus being lazy).
IEnumberable for when you only need to loop over the collection. IList for when you need the method that the interface offers, Add, Remove, InsertAt, etc, etc.
Just as another point, collection interfaces are very important when receiving parameters, but when used internally within a function or even as a returned value its often better to use the concrete type as you are avoid vtable function lookups. The code analyzer in visual studio will even recommend this as well.
IEnumerable is something you can iterate over. ICollection is something where you know that you will eventually finish. You can easily create an infinite IEnumerable
Not always true because list also implements IEnumerable and you don't need to materialize a list to get values since the values are already present. The deferred execution scenario you're talking about comes into picture when an IEnumerable is returned from an iterator block.
Not completely true. Calling ToList forces dotnet to iterate through the whole collection, but you do not need to do so in order to read the values (you can iterate). The biggest difference is when you iterate twice.
Isn't that just for ORMs though, like EntityFramework? If you simply have a method that takes an IEnumerable it could be a List, but it will only behave like a read-only enumerable.
It's true for anything that's returning things through a "yield return" which is what the underlying linq extensions are doing... Including EF. EF just does it with way more magic than usual. It sends the whole linq query through an ExpressionTreeBuilder first to convert it to sql
You always end up using it one way or another. I use a concrete type most of the time, List or []. But I also work in environments where IEnumerable isn't too common.
@@MilanJovanovicTech i always materialize the list and make joined queries with efcore. That's why i didn't feel the need to use it somehow. Can you make me a good example if it's better to use other than materialize the list already?
@@andrasmargittai6663 you don't need to materialize what is not yet finished as enumerable with LINQ extension methods. Sometimes it's good to pass IEnumerable and materialize it only on last step
Little missleading explanation. IEnumerable is just an interface that gives you iterator. You decribing EF implemantation.
For example to get 10th element from IEnumerable you cannot just get it by adress - arr[9]. You need to itereate by every element - one by one, as a seqeance . This gives flexibility for diffrent implementations because that way data structure that is impelementing IEnumerable can optimize memory consumption and fetch only one element at the time.
If you are have 1000 element list but you want to read only first, all elements of the List will be loaded to the memory (such a waste) . If you use IEnumerable it should load only one - when accessed.
Entity Framework implements IEnumebrable(iQuerable). If you call "toList" It will load all selected record from database to the memory (because you need to have all data to create a list). if you don't call "to List" and just itereate EF will load one element at the time (creating many select querries to the database).
Bad or just non-detailed? There is a difference.
@@MilanJovanovicTech Sorry. I have corrected my previous comment.
His explanation was on point, and not "dependent on EF implementation". IEnumerables are really lazy , they describe an interface for iteration and they return an IEnumerator that is iterated one element at a time (it does not matter how the underlying implementation works, it is made to serve only when iterated, thus being lazy).
It's not "just an interface" - it's fairly magical - it let's you yield return without creating a list.. It's not just EF
@@ronsijm it is just an interface. There is nothing magica in iterator.
Innumerable is only lazy when it’s implemented by an iterator state machine (yield). A List is also IEnumerable.
That is correct
IEnumberable for when you only need to loop over the collection. IList for when you need the method that the interface offers, Add, Remove, InsertAt, etc, etc.
I end up using List or [] for the latter
Yes it's more efficient in terms of resources. Only use list when you need its additional functions. The same applies to ICollection
Just as another point, collection interfaces are very important when receiving parameters, but when used internally within a function or even as a returned value its often better to use the concrete type as you are avoid vtable function lookups. The code analyzer in visual studio will even recommend this as well.
Heads up that IList doesn’t have AddRange for example. It’s one of those methods that is only present in List.
IEnumerable is something you can iterate over. ICollection is something where you know that you will eventually finish.
You can easily create an infinite IEnumerable
Nice way to compare them
Very Informative
Glad you liked it
Not always true because list also implements IEnumerable and you don't need to materialize a list to get values since the values are already present. The deferred execution scenario you're talking about comes into picture when an IEnumerable is returned from an iterator block.
You can also get there by chaining LINQ operators
Yea, I feel like this is more the difference between ConvertAll (non-linq) and Select (linq). Not List vs IEnumerable
Kind of
Not completely true. Calling ToList forces dotnet to iterate through the whole collection, but you do not need to do so in order to read the values (you can iterate).
The biggest difference is when you iterate twice.
Good idea for another video
Isn't that just for ORMs though, like EntityFramework?
If you simply have a method that takes an IEnumerable it could be a List, but it will only behave like a read-only enumerable.
Not really. When you call Where/Select even on an underlying List, it won't execute until it's enumerated over.
@@MilanJovanovicTech Ok, thanks for clarifying 😄 I'm sure I've read it before but just forgotten about it.
It's true for anything that's returning things through a "yield return" which is what the underlying linq extensions are doing... Including EF. EF just does it with way more magic than usual. It sends the whole linq query through an ExpressionTreeBuilder first to convert it to sql
When do you recommend ienumerable?
You always end up using it one way or another. I use a concrete type most of the time, List or []. But I also work in environments where IEnumerable isn't too common.
@@MilanJovanovicTech i always materialize the list and make joined queries with efcore. That's why i didn't feel the need to use it somehow. Can you make me a good example if it's better to use other than materialize the list already?
@@andrasmargittai6663 you don't need to materialize what is not yet finished as enumerable with LINQ extension methods. Sometimes it's good to pass IEnumerable and materialize it only on last step
Nice tip!
Thank you!