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
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
大规模微服务破局之道：合并编译
生成式 3D 技术实践: 重塑产品设计的可能性
新型 IM 系统建设和呼叫场景优化的探索和实践
评论