BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

IQueryable对于API是个错误的选择吗?

| 作者 Roopesh Shenoy 关注 0 他的粉丝 ,译者 曹如进 关注 0 他的粉丝 发布于 2012年4月12日. 估计阅读时间: 2 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

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客户端中取回所需的数据。

亲爱的读者,你是怎么考虑的呢?灵活性带来的好处是否能盖过抽象泄露呢?

查看英文原文:Is IQueryable A Bad Choice For APIs?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

有利有弊 by 孙 长宇

首先,IQueryable接口的确很灵活,带来了很多方便,我也很喜欢用。
但是,必须承认,当你得到一个IQueryable对象的时候,你是无法确定它“能做什么,不能做什么”的,原因在于你并不确定该对象的查询提供程序(IQueryProvider)是否能解析并执行Expression Tree中所有的Expression。
当然我这样说并不一定准确,你完全可以反射得到IQueryProvider的类型并判断他是否支持某种查询,但这样做的复杂程度可想而知,而且完全失去了定义IQueryable的意义。

Re: 有利有弊 by 曾 润锋

IQueryable<T> 才好用</t>

Re: 有利有弊 by 孙 长宇

针对正文中讨论的问题及上下文场景,这里的“IQueryable”应该是个泛指,楼上不必计较是不是泛型版本的实现,因为正文讨论的问题不是IQueryable<T>就能解决的。</t>

re by l db

如果是是针对构造在内存中的list感觉还可以,但是如果是对数据库查询最好不要,不够健壮

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

4 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT