asp.net-mvc - 是时候开始将 IQueryable 而不是 IList 返回到我的 Web UI/Web API 层了吗？

Question

我有一个多层应用程序，它以所有数据访问的存储库模式开始，并将 IQueryable 返回到服务层。包含所有业务逻辑的服务层将 IList 返回给 Controller (注意:我将 ASP.NET MVC 用于 UI 层)。在数据访问层返回 IQueryable 的好处是它允许我的存储库非常简单，并且可以延迟数据库查询。但是，我在我的服务层中触发了数据库查询，以便我的单元测试更可靠，并且我没有让 Controller 灵活地 reshape 我的查询。但是，我最近遇到了几种情况，其中将查询的执行推迟到 Controller 会显着提高性能，因为 Controller 必须对特定于 UI 的数据进行一些预测。此外，随着 oData 之类的出现，我开始怀疑端点(例如 Web UI 或 Web API)是否应该直接与 IQueryable 一起工作。你怎么认为？是时候开始将 IQueryable 从服务层返回到 UI 层了吗？还是坚持使用 IList？

这个线程在这里:To return IQueryable<T> or not return IQueryable<T>
似乎保证将 IList 返回到 UI 层，但我想知道是否由于新兴技术和技术而发生了变化。

Answer 1

我喜欢尽可能坚持使用 IQueryable 接口(interface)，唯一的问题是当你最终在 Controller 级别进行复杂的过滤或重新查询时，如果你有类似的东西:

//DATA ACCESS
    public IQueryable<T> GetStudents()
    {
    return db.Students;
    }

在您的 Controller 中，您会进行一些重新锐化，因为您的客户端想要过滤该结果的一些数据，您肯定会很想在 Controller 级别执行此操作:

var result = obj.GetStudents().Where(d=>d...);

对我来说没问题，但只是成像如果任何其他模块需要使用相同的过滤器，你不能调用它，因为它在 Controller 级别。
所以对我来说，这是在 DRY、灵 active 和系统的可扩展性之间取得平衡的事情。
如果您需要一个完全可扩展的系统，您将需要对 GetStudents() 方法进行一些或多次重载，并摆脱 Controller 级别的任何重新锐化。