4

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

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

4

1 回答 1

3

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

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

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

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

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

于 2010-03-30T19:26:53.353 回答