ASP MVC:服务是否应返回IQueryable?

目前,这听起来很吸引人,但是 really isn't .

不,你的控制器根本不应该处理任何复杂的逻辑。让它们保持苗条;模型(而不是DAO)应该把控制器送回它需要传递到视图上的所有内容。

在控制器类中看到查询(甚至是可查询的)是我认为是一种代码味道。

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

GetCustomersByLastname( string lastname )

很快变成

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

一次又一次。布莱克!

使用iqueryable,您可以采用正交的方式实现分页和排序,例如利用ipagedlist项目。返回iqueryable还可以让您轻松地访问total object.count(),而无需对数据层进行更多的歪曲。

@罗伯特关于iqueryable等于fat控制器的论点是非常不可靠的。一个胖的控制器类似于以前的膨胀的.aspx.cs页面。如果您所做的一切都是连接到DAL,然后将结果从查询技术中传送出去,那么您就不会从查询技术中获得“胖”,而是从将大量逻辑推送到单个类中获得它。由于数据访问方法的原因,您不会得到胖控制器,除非您开始在内部滚动日志记录、通知和其他正交问题。

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 );
}

我看不出有什么令人信服的区别。

@马克·西曼的回答同样不可靠。当然,您可以在项目中间更改整个数据层,但无论您是多么抽象化,这都将是一个复杂的灾难。他使用的示例是从linq2sql切换到WindowsAzure的表存储。RDBMS到密钥/值存储?症结在于您的存储库实现?从RDBMS到一个钥匙/价值商店将会是一种疯狂,不管怎样都会是可怕的。

马克在他的论点中也提到了领域驱动的设计。这是你建筑的系统类型吗?是否有足够的“领域”而不是纯粹的CRUD场景使这种方法有价值?如果不是,那何必麻烦呢?

使用和LINQ以及IQueryable接口可以减少切换数据层的痛苦。如果您在支持LINQ和iqueryableProvider的ORM之间切换(我认为这是名称),那么只有下游代码才关心这个更改。您的控制器将保持目前市场上大多数ORM的相同切换。

如果你遵循“胖模型,瘦控制器”的模式,那就不。

在上看到这个帖子 Fat Controller anti-pattern .