i already know that IQueryable will not return all the results from the database until they are called, thay can be used for deferred execution. while Ienumerable will return all the results from the DB at once. but i note that in a lot of examples they
use Ienumerable when creating viewmodel classes such as
public class ShoppingCartViewModel {
**public IEnumerable<Product> Products { get; set; }**
public decimal CartTotal { get; set; }
public string Message { get; set; }
}
Question 1) so what will be the differences if i use "public IQueryable Products { get; set; }" instead, in the above codde
Question 2) when defining model objects most of the examples uses List such as:-
public partial class Genre
{
public int GenreId { get; set; }
public string Name { get; set; }
public string Description { get; set; }
**public List Albums { get; set; }** } }
so why to use List instead of IQueryable or even IEnumerable?
question 3 ) why when i create a view ; then why the automatic code will use Ienumerable such as , instead of IQueryable or LIST ??
@model IEnumerable<E.ViewModels.DateGroup>
Hint:- i am using Entity framework and repository design pattern.
Also note that IEnumerable does NOT mean immediate execution. Like IQueryable, it's only executed when enumerated over. The main difference
is that in addition to being IEnumerable, IQueryable also has a reference to a query provider and a query expression.
"If I can see further than anyone else, it is only because I am standing on the shoulders of giants."blog: www.heartysoft.com twitter: @ashic
Marked as answer by HeartattacK on Jan 31, 2012 09:40 AM
thanks for the link, but it seems the link was created 3 years ago and i think they were talking about the differences before working wiht entity framework as in my case.
No...IQueryable has nothing specific about EF, Linq to Sql etc. It's part of .NET. When working with EF, the query provider is the EF query provider. Similarly when working with L2S, it's the L2S query provider. IQueryable is just an IEnumerable with the
query provider and expression references added.
"If I can see further than anyone else, it is only because I am standing on the shoulders of giants."blog: www.heartysoft.com twitter: @ashic
Marked as answer by HeartattacK on Jan 31, 2012 09:40 AM
its poor design to pass queries to view, because any sql error will hapen in the view rather than the controller. also if you iterate more than once, the query is called more than once
@foreach (var item in list) {
}
total @list.Count
will run the query twice if its a IQueryable.
in models, the binder can only work with non-abstract object, it has no way to add an item to a IEnumerable, becuase it doesn't know what object to create for the collection. so for collections you can only use List<> or an array if you want postback bindin
by the default binder. if you use a custom binder, than you can use wherever you want.
IQUeryable: As already said by Bruce one should avoid passing Iqueryable to Views.It is not a good place to handle errors...so better getting rid of delayed execution before passing to Views.
IEnumerable. Actually the model binder is not able to bind an enumerable because it is a too generic Interface, and it is not able to choose a concrete class to create that implements the IEnumerable. HOWEVER, you are not forced to use concrete
classes, the model binder is able to bind also ICollection<T>, ILIst<T> and IDictionary<T, M>, because each of the above interfaces maps quite naturally in concrete classes...ICollection to array, ILIst to a List and IDictionary to a Dictionary...An IEnumerable
is an ancestor of both the above interfaces() also IDictionary<T, M> implements IEnumerable<KeyValuePair<T, M>>) so...it will be difficult for the model binder to choose among them...(in partricular it is not able to verify if the IEnumerable is an IDictionary,
or some other complex type defined by the developer)
List<T>: The advantage of using a List is that you can use efficiently indexers in lambda expressions like m => m.MyList[i]. Using lambda expressions with indexers creates the right names for all the field and enables the Model Binder to
bind correctly the list when the view is posted, as explained here: http://haacked.com/archive/2008/10/23/model-binding-to-a-list.aspx. Obviously you can create the right names
also manually by using the TextBox type helpers instead of the TextBoxFor type...but the last is safer to use since you cannot write a WRONG name (VS 2010 immediately signal the error)
its poor design to pass queries to view, because any sql error will hapen in the view rather than the controller. also if you iterate more than once, the query is called more than once
@foreach (var item in list) {
}
total @list.Count
will run the query twice if its a IQueryable.
in models, the binder can only work with non-abstract object, it has no way to add an item to a IEnumerable, becuase it doesn't know what object to create for the collection. so for collections you can only use List<> or an array if you want postback bindin
by the default binder. if you use a custom binder, than you can use wherever you want.
Passing IEnumerable doesn't mean that there won't be queries from the view. You can assign an IQueryable to an IEnumerable. If the view does a Count() on the IEnumerable and it's been assigned an IQueryable, then the view will be queryng the data store.
Viewmodels should use List or Array or something similar that already has fetched the necessary data so that data store queries aren't done in the views.
"If I can see further than anyone else, it is only because I am standing on the shoulders of giants."blog: www.heartysoft.com twitter: @ashic
Marked as answer by HeartattacK on Jan 31, 2012 09:40 AM
It is good practice to pass List<T> or Arrays because tthey can be efficiently indexed as i detailed in my previous post. However one can also apply a ToList operator to an IQueryable and then place the List<T> you get into an ICollection or IList if for some
reason one need to work with interfaces....and if one doesn't need indexers
johnjohn1231...
Participant
922 Points
871 Posts
IQueryable vs IEnumerable VS List<>
Jan 21, 2012 09:30 PM|LINK
i already know that IQueryable will not return all the results from the database until they are called, thay can be used for deferred execution. while Ienumerable will return all the results from the DB at once. but i note that in a lot of examples they use Ienumerable when creating viewmodel classes such as
public class ShoppingCartViewModel { **public IEnumerable<Product> Products { get; set; }** public decimal CartTotal { get; set; } public string Message { get; set; } }Question 1) so what will be the differences if i use "public IQueryable Products { get; set; }" instead, in the above codde
Question 2) when defining model objects most of the examples uses List such as:-
public partial class Genre { public int GenreId { get; set; } public string Name { get; set; } public string Description { get; set; } **public List Albums { get; set; }** } } so why to use List instead of IQueryable or even IEnumerable?
question 3 ) why when i create a view ; then why the automatic code will use Ienumerable such as , instead of IQueryable or LIST ??
Hint:- i am using Entity framework and repository design pattern.
BR
HeartattacK
All-Star
55262 Points
5917 Posts
Moderator
MVP
Re: IQueryable vs IEnumerable VS List<>
Jan 21, 2012 10:47 PM|LINK
Have a look here:
http://stackoverflow.com/questions/252785/what-is-the-difference-between-iqueryablet-and-ienumerablet
Also note that IEnumerable does NOT mean immediate execution. Like IQueryable, it's only executed when enumerated over. The main difference is that in addition to being IEnumerable, IQueryable also has a reference to a query provider and a query expression.
blog: www.heartysoft.com
twitter: @ashic
johnjohn1231...
Participant
922 Points
871 Posts
Re: IQueryable vs IEnumerable VS List<>
Jan 21, 2012 11:01 PM|LINK
thanks for the link, but it seems the link was created 3 years ago and i think they were talking about the differences before working wiht entity framework as in my case.
BR
HeartattacK
All-Star
55262 Points
5917 Posts
Moderator
MVP
Re: IQueryable vs IEnumerable VS List<>
Jan 21, 2012 11:04 PM|LINK
No...IQueryable has nothing specific about EF, Linq to Sql etc. It's part of .NET. When working with EF, the query provider is the EF query provider. Similarly when working with L2S, it's the L2S query provider. IQueryable is just an IEnumerable with the query provider and expression references added.
blog: www.heartysoft.com
twitter: @ashic
bruce (sqlwo...
All-Star
36850 Points
5445 Posts
Re: IQueryable vs IEnumerable VS List<>
Jan 22, 2012 01:08 AM|LINK
its poor design to pass queries to view, because any sql error will hapen in the view rather than the controller. also if you iterate more than once, the query is called more than once
@foreach (var item in list) {
}
total @list.Count
will run the query twice if its a IQueryable.
in models, the binder can only work with non-abstract object, it has no way to add an item to a IEnumerable, becuase it doesn't know what object to create for the collection. so for collections you can only use List<> or an array if you want postback bindin by the default binder. if you use a custom binder, than you can use wherever you want.
francesco ab...
All-Star
20912 Points
3279 Posts
Re: IQueryable vs IEnumerable VS List<>
Jan 22, 2012 09:23 AM|LINK
IQUeryable: As already said by Bruce one should avoid passing Iqueryable to Views.It is not a good place to handle errors...so better getting rid of delayed execution before passing to Views.
IEnumerable. Actually the model binder is not able to bind an enumerable because it is a too generic Interface, and it is not able to choose a concrete class to create that implements the IEnumerable. HOWEVER, you are not forced to use concrete classes, the model binder is able to bind also ICollection<T>, ILIst<T> and IDictionary<T, M>, because each of the above interfaces maps quite naturally in concrete classes...ICollection to array, ILIst to a List and IDictionary to a Dictionary...An IEnumerable is an ancestor of both the above interfaces() also IDictionary<T, M> implements IEnumerable<KeyValuePair<T, M>>) so...it will be difficult for the model binder to choose among them...(in partricular it is not able to verify if the IEnumerable is an IDictionary, or some other complex type defined by the developer)
List<T>: The advantage of using a List is that you can use efficiently indexers in lambda expressions like m => m.MyList[i]. Using lambda expressions with indexers creates the right names for all the field and enables the Model Binder to bind correctly the list when the view is posted, as explained here: http://haacked.com/archive/2008/10/23/model-binding-to-a-list.aspx. Obviously you can create the right names also manually by using the TextBox type helpers instead of the TextBoxFor type...but the last is safer to use since you cannot write a WRONG name (VS 2010 immediately signal the error)
Mvc Controls Toolkit | Data Moving Plug-in Videos
HeartattacK
All-Star
55262 Points
5917 Posts
Moderator
MVP
Re: IQueryable vs IEnumerable VS List<>
Jan 22, 2012 10:30 AM|LINK
Passing IEnumerable doesn't mean that there won't be queries from the view. You can assign an IQueryable to an IEnumerable. If the view does a Count() on the IEnumerable and it's been assigned an IQueryable, then the view will be queryng the data store.
Viewmodels should use List or Array or something similar that already has fetched the necessary data so that data store queries aren't done in the views.
blog: www.heartysoft.com
twitter: @ashic
francesco ab...
All-Star
20912 Points
3279 Posts
Re: IQueryable vs IEnumerable VS List<>
Jan 22, 2012 09:38 PM|LINK
Mvc Controls Toolkit | Data Moving Plug-in Videos