ASP MVC：服务应该返回IQueryable吗？

你怎么看？ 如果您的DAO返回IQueryable以在控制器中使用它吗？

Answer 1

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

Answer 2

不。您的控制器根本不应该处理任何复杂的逻辑。 保持苗条; 模型（不是DAO）应该将Controller传递回View所需的一切。

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

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，然后将结果发送出去，而不是从您的查询技术中获得“肥胖”，那么您可以通过在单个类中输入大量逻辑来获得它。 除非您开始在内部滚动日志记录，通知和其他正交问题，否则您不会因为数据访问方法而获得Fat Controller。

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

VS：

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

我没有看到令人信服的差异。

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

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

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

Answer 4

如果你遵循“胖模型，瘦的控制器”范例那么没有。

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