要返回IQueryable <T>还是不返回IQueryable <T>

Question

我有一个存储库类，将我的LINQ包装到SQL数据上下文中。存储库类是业务线类，其中包含所有数据层逻辑（以及缓存等）。

这是我的repo界面的v1。

public interface ILocationRepository

{

    IList<Location> FindAll();

    IList<Location> FindForState(State state);

    IList<Location> FindForPostCode(string postCode);

}

但是为了处理FindAll的分页，我正在辩论是否公开IQueryable <ILocation>而不是IList来简化诸如分页之类的接口。

从数据存储库中暴露IQueryable的利弊是什么？

很感谢任何形式的帮助。

Answer 1

优点；可组合性：来电者可以添加过滤器呼叫者可以添加分页来电者可以添加排序等等缺点&nbsp;不可测试性：您的存储库不再可以进行单元测试。您不能依靠：a：它起作用，b：它做什么；调用者可以添加一个不可翻译的函数（即没有TSQL映射；在运行时中断）呼叫者可以添加一个过滤器/排序，使其像狗一样执行由于调用者期望IQueryable<T>是可组合的，因此它排除了不可组合的实现-或迫使您为其编写自己的查询提供程序这意味着您无法优化/分析DAL为了稳定起见，我考虑不公开资料库IQueryable<T>或不公开Expression<...>资料库。这意味着我知道存储库的行为方式，并且我的上层可以使用模拟，而不必担心“实际的存储库是否支持此操作？”&nbsp;（强制进行集成测试）。我仍然使用IQueryable<T>等内部信息库-但不下来的边界。我在这里对这个主题发表了更多想法。将分页参数放在存储库接口上同样容易。您甚至可以使用扩展方法（在接口上）添加可选的分页参数，以便具体类仅可以实现1种方法，但调用者可以使用2或3个重载。