Using IEnumerable<T> and IQueryable<T> in a generic repository
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 (eg 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).
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.
链接地址: http://www.djcxy.com/p/62098.html