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

我有一个存储库类，将我的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的利弊是什么？

很感谢任何形式的帮助。

优点；可组合性：

• 来电者可以添加过滤器
• 呼叫者可以添加分页
• 呼叫者可以添加排序
• 等等

缺点 不可测试性：

• 您的存储库不再可以进行单元测试。您不能依赖a：它起作用，b：它做什么；
  • 调用者可以添加一个不可翻译的函数（即没有TSQL映射；在运行时中断）
  • 呼叫者可以添加一个过滤器/排序，使其性能像狗一样
• 由于调用者期望IQueryable<T>是可组合的，因此它排除了不可组合的实现-或迫使您为其编写自己的查询提供程序
• 这意味着您无法优化/分析DAL

为了稳定起见，我已选择不公开IQueryable<T>或不在Expression<...>自己的存储库中。这意味着我知道存储库的行为方式，并且我的上层可以使用模拟，而不必担心“实际的存储库是否支持此操作？” （强制进行集成测试）。

我仍然使用IQueryable<T>等内部信息库-但不下来的边界。我在这里对这个主题发表了更多想法。将分页参数放在存储库界面上也很容易。您甚至可以使用扩展方法（在接口上）添加可选的分页参数，以便具体类仅可以实现1个方法，但调用者可以使用2或3个重载。

正如前面的答案所提到的，公开IQueryable使调用者可以使用IQueryable本身进行播放，这将变得危险。

封装业务逻辑的首要职责是维护数据库的完整性。

您可以继续公开IList，并可能如下更改参数，这就是我们正在做的...

public interface ILocationRepository
{
    IList<Location> FindAll(int start, int size);
    IList<Location> FindForState(State state, int start, int size);
    IList<Location> FindForPostCode(string postCode, int start, int size);
}

如果size == -1，则全部返回...

替代方法...

如果仍要返回IQueryable，则可以在函数内部返回List的IQueryable。例如。

public class MyRepository
{
    IQueryable<Location> FindAll()
    {
        List<Location> myLocations = ....;
        return myLocations.AsQueryable<Location>;
        // here Query can only be applied on this
        // subset, not directly to the database
    }
}

第一种方法比内存有一个优势，因为您将返回较少的数据而不是全部。

我建议您使用IEnumerable代替IList，这样您将具有更大的灵活性。

这样，您就可以从Db中仅获取您真正要使用的那部分数据，而无需在存储库中完成额外的工作。

样品：

// Repository
public interface IRepository
{
    IEnumerable<Location> GetLocations();
}

// Controller
public ActionResult Locations(int? page)
{
    return View(repository.GetLocations().AsPagination(page ?? 1, 10);
}

超级干净简单。