I have read a number of posts regarding the implementation of a generic repository. I have also read a number of posts that explain the difference between exposing IEnumerable vs. IQueryable from my repository.
I would like the flexibility of having my data filtered in the database (rather than in memory by the client) but want to avoid having to define a separate repository interface for all of my entities (and concrete classes that implement those interfaces).
So far my repository looks like this:
public interface IRepository<T>
{
IEnumerable<T> GetAll();
IEnumerable<T> Find(Expression<Func<T, bool>> where);
void Add(T entity);
void Attach(T entity);
void Delete(T entity);
}
and an example of a concrete implementation is:
public class Repository<T> : IRepository<T> where T : class
{
private DbContext _context;
private DbSet<T> _entitySet;
public Repository(DbContext context)
{
_context = context;
_entitySet = _context.Set<T>();
}
public IEnumerable<T> GetAll()
{
return _entitySet;
}
public IEnumerable<T> Find(Expression<Func<T, bool>> where)
{
return _entitySet.Where(where);
}
public void Add(T entity)
{
_entitySet.Add(entity);
}
public void Attach(T entity)
{
_entitySet.Attach(entity);
}
public void Delete(T entity)
{
_entitySet.Remove(entity);
}
}
In this case my repository uses DbContext
so what I would like to know is how this works with the generic interface:
IQueryable<T>
derives from IEnumerable<T>
. In My find method I am returning an IQueryable<T>
object but the client only sees this as an IEnumerable<T>
. Does this mean that if I carry out any subsequent queries on the IEnumerable<T>
object it will actually perform the operations on the database and only return the results (because the object is a IQueryable
in this case)? Or,Where
clause that is passed into the Find
method is executed on the database and any subsequent queries that are performed on the IEnumerable<T>
object are performed on the client. Or,IEnumarable<T>
, IQueryable<T>
and Linq
works.Update:
I am actually fairly surprised at the answers I have received in the comments. My original repository returned IQueryable and subsequent research led me to believe this was a bad thing to do (e.g. if my viewModel accepts a repository in its constructor it can call any query it wants which makes it is more difficult to test).
All solutions I have seen for this so far involve create entity specific repositories so that IQueryable is not exposed (The only difference I guess is that I am doing this in a generic way).
Both IEnumerable and IQueryable are forward collection. Querying data from a database, IEnumerable execute a select query on the server side, load data in-memory on a client-side and then filter data. Querying data from a database, IQueryable execute the select query on the server side with all filters.
So if you working with only in-memory data collection IEnumerable is a good choice but if you want to query data collection which is connected with database `IQueryable is a better choice as it reduces network traffic and uses the power of SQL language.
IQueryable is faster than IEnumerable. In addition to Munesh Sharma's answer:IEnumerable loads data in-memory and then apply filters to it one by one but IQueryable apply filters all at once and return the result.
The IQueryable interface inherits the IEnumerable interface so that if it represents a query, the results of that query can be enumerated. Enumeration causes the expression tree associated with an IQueryable object to be executed. The definition of "executing an expression tree" is specific to a query provider.
Because you are returning IEnumerable<T>
all subsequent calls will be done in memory (locally).
One thing to keep in mind is that LINQ operates with a set of extension methods. There are extension methods for IQueryable<T>
which support all of the necessary wiring to perform queries in locations other than locally, and extension methods for IEnumerable<T>
that just work locally.
Note that which of these is selected is based on the compile time type, not the run time type. So an IQueryable
that is cast to an IEnumerable
will be treated as an IEnumerable
. This is different than the way class normally work (thanks to polymorphism) however it allows the call site control over how to perform these operations.
An example of where this is useful is when you need to get all of the records in the table and then count them. There is no need to perform the count in SQL if you are going to get all the results anyway.
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