Mark Seemann 在他的一篇名为“ IQueryable 之紧耦合”的文章中建议不要在设计 API 时暴露 IQueryable 接口，并列出了几点原因。
……IQueryable 接口是.NET 提供的 Header Interface 中一个优秀的接口示例。不过，我们几乎没办法完整地实现这个接口。
言下之意就是说，你没法确保方法会返回 IQueryable 接口的一个完整实现。
虽然该接口非常灵活、表达力很强，但是有个例外，那就是我们总能够写出一个查询让给定的 provider（供应程序）没法转化。
IQueryable 唯一的完整实现是内存实现。
Mark 说，这种方式会导致抽象泄露（leaky abstraction），因为大部分情况下 IQueryable 都会由代码中的 Store provider 实现。
虽然这种说法很有道理，但是反过来想想，抽象泄露又有多大问题呢？使用它至少能够在我们可接受的范围内让写代码变得简单些也说不定呢？
比方说，如果 ASP.NET Web API 的返回类型为 IQueryable，那么它可以通过请求参数让同样用于过滤数据的webapi 变得更加简单。类似地，WCF RIA Service 中的DomainContext 方法返回的也是IQueryable，客户端可以借助它可在XAML 中使用过滤描述符（filter descriptor）或从 JQuery 客户端中取回所需的数据。
亲爱的读者，你是怎么考虑的呢？灵活性带来的好处是否能盖过抽象泄露呢？
暂无签名
最新发布
揭秘 InputFormat：掌控 Map Reduce 任务执行的利器
2012-01-16
LinkedIn 宣布 1.19 亿美元收购文件分享网站 SlideShare
2012-05-06
腾讯云云原生提质增效实践精选集 2024
《2024腾讯云云原生提质增效实践精选集》出炉，5大热门技术领域，13个行业精选标杆案例，痛点到解决方案全...
为 Coding Agent 构建智能上下文：Qoder 的 Context Engineering 实践
多智能体协作与博弈——打造最高效的“AI 团队”
DeepResearch如何在企业内落地
评论