c# - ASP MVC：服务应该返回 IQueryable 的吗？

Question

你怎么看？您的 DAO 是否应该返回一个 IQueryable 以在您的控制器中使用它？

Answer 1

不，您的控制器根本不应该处理任何复杂的逻辑。保持苗条；模型（而不是 DAO）应该把它需要传递给视图的所有东西交给控制器。

在 Controller 类中看到查询（甚至可查询）是我认为是代码异味的东西。

Answer 2

目前，这听起来很有吸引力，但实际上并非如此。

Answer 3

我喜欢将 IQueryable 传递给我的控制器，因为在我的应用程序开发的整个生命周期中，我不必在每个 DAO 方法和接口中创建蹩脚的分页和排序方法。

GetCustomersByLastname( string lastname )

迅速成为

GetCustomersByLastname( string lastname, string sortcolumn, int pagesize, int page )

一次又一次，一次又一次。布莱克！

使用 IQueryable，您可以以正交方式实现分页和排序，例如利用 IPagedList 项目。返回 IQueryable 还可以让您轻松访问总对象 .Count() ，而不会对数据层产生更多反常。

@Robert 的 IQueryable 等于胖控制器的论点非常不稳定。Fat 控制器类似于过去臃肿的 .aspx.cs 页面。如果您所做的只是连接到您的 DAL，然后将结果从您的查询技术中获得“肥胖”，那么您可以通过在单个类中塞入大量逻辑来获得它。由于您的数据访问方法，您不会获得胖控制器，除非您开始在内部滚动日志记录、通知和其他正交关注点。

public ActionResult Detail( string searchTerm )
{
    var model = MyDAL.MyObjects( searchTerm );
}

与：

public ActionResult Detail( string searchTerm )
{
    var model = MyDAL.MyObjects.Where( x => x.Name == searchTerm );
}

我看不出有什么引人注目的区别。

@Mark Seemann 的回答同样不稳定。当然，您可以在项目中间更改整个数据层，但无论您多么抽象，这都将是一场复杂的灾难。他使用的示例是从 Linq2Sql 切换到 Windows Azure 的表存储。RDBMS 到键/值存储？痛点是您的存储库实施？从 RDBMS 到 Key/Value 存储将是一些疯狂的事情，无论如何这将是可怕的。

Mark 在他的论点中还提到了领域驱动设计。那是您建筑的系统类型吗？是否有足够的“领域”而不是纯粹的 CRUD 场景使这种方法有价值？如果不是那么为什么要打扰？

无论如何，使用 LINQ 和 IQueryable 接口可以减少切换数据层的痛苦。如果您在支持 LINQ 和 IQueryableProvider（我认为这就是名称）的 ORM 之间切换，那么只有下游代码才关心该更改。您的控制器将保持与现在市场上大多数 ORM 之间的相同切换。

Answer 4

如果您遵循“胖模型，瘦控制器”范式，那么就不会。

请参阅有关Fat Controller 反模式的这篇文章。