我已经阅读了一些关于通用存储库实现的帖子。我还阅读了一些帖子,解释了从我的存储库中暴露IEnumerable和IQueryable之间的区别。
我希望在数据库中过滤数据的灵活性(而不是客户端在内存中),但是要避免为我的所有实体(以及实现这些接口的具体类)定义单独的存储库接口
到目前为止,我的存储库看起来像这样:
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);
}
和具体实现的一个例子是:
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);
}
}
在这种情况下,我的存储库使用DbContext
所以我想知道的是它如何与通用接口一起使用:
IQueryable<T>
派生自IEnumerable<T>
。在我的find方法中,我返回一个IQueryable<T>
对象,但客户端只将其视为IEnumerable<T>
。这是否意味着如果我对IEnumerable<T>
对象执行任何后续查询,它将实际执行数据库上的操作并仅返回结果(因为对象是< / em> IQueryable
在这种情况下)?或者,Where
方法的Find
子句,并在客户端上执行对IEnumerable<T>
对象执行的任何后续查询。或者,IEnumarable<T>
,IQueryable<T>
和Linq
的工作原理。更新
我对评论中收到的答案感到相当惊讶。我的原始存储库返回了IQueryable,随后的研究使我相信这是一件坏事(例如,如果我的viewModel在其构造函数中接受了一个存储库,它可以调用它想要的任何查询,这使得测试更加困难)。
到目前为止,我所看到的所有解决方案都涉及创建特定于实体的存储库,以便不暴露IQueryable(我猜的唯一区别是我以通用方式执行此操作)。
答案 0 :(得分:6)
因为您要返回IEnumerable<T>
所有后续调用都将在内存(本地)中完成。
要记住的一件事是LINQ使用一组扩展方法。 IQueryable<T>
有一些扩展方法,它们支持在本地以外的位置执行查询所需的所有连线,以及只在本地工作的IEnumerable<T>
扩展方法。
请注意,选择了哪一个基于编译时类型,而不是运行时类型。因此,投放到IQueryable
的{{1}}将被视为IEnumerable
。这与类通常工作的方式不同(多亏了多态),但它允许调用站点控制如何执行这些操作。
这有用的一个示例是当您需要获取表中的所有记录然后对它们进行计数时。如果要获得所有结果,则无需在SQL中执行计数。