是时候开始将 IQueryable<T> 而不是 IList<T> 返回到我的 Web UI/Web API 层了吗？答案

【问题标题】：Time to start returning IQueryable<T> instead of IList<T> to my Web UI / Web API Layer?是时候开始将 IQueryable<T> 而不是 IList<T> 返回到我的 Web UI/Web API 层了吗？
【发布时间】：2011-02-02 07:58:24
【问题描述】：

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

这里的帖子：To return IQueryable<T> or not return IQueryable<T> 似乎可以保证将 IList 返回到 UI 层，但我想知道是否会因为新出现的技术和技术而发生变化。

【问题讨论】：

实际上您链接的线程是不可知的；它不赞成一种或另一种方式。测试驱动的开发人员总是倾向于修复接口，这样它就更可预测了。就个人而言，我喜欢 IQueryable 的灵活性和延迟执行。在将 ToList() 插入 UI 之前，您始终可以调用它。

标签： asp.net-mvc repository-pattern iqueryable multi-tier

【解决方案1】：

我喜欢尽可能坚持使用 IQueryable 接口，唯一的问题是当您最终在控制器级别进行复杂的过滤或按需重新查询时，如果您有类似的情况：

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

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

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

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

【讨论】：