9

提前了解“仅仅因为提供了一项功能并不能使它成为一个好主意”的警告......

从外观上看，符合 OData 的签名要求您返回 IQueryable。

例如：

[Queryable]
public IQueryable<MyModel> Get()
{
    return _repo.GetAll().AsQueryable();
}

但是，最近和最近的许多文章将 IQueryable 描述为：

  • 泄漏
  • ' Causing Heavy Lifting ' 示例：允许用户抓取整张桌子
  • 存在安全和扩展问题，因为它允许对查询本身进行大量修改
  • 也可能导致延迟执行的问题（因为它的可查询性质）

我的问题是：
您是否觉得 IQueryable 和 OData 的功能超过了上述问题？

在回答时，我希望人们谈论：

  • 为什么或者为什么不？
  • 我应该什么时候使用它？
  • 您只在某些 WebAPI 调用中使用...还是用于所有 WebAPI 调用？
  • 那些不是 IEnumarable 对象的个别模型呢？

...像这样的东西。

背景：我问的不仅仅是因为上面列出的项目。还因为 OData 作为“行业标准”而不是您工具箱中的工具出售给我们。因此，实现这一点将从根本上改变我们的 WebAPI 调用（我目前工作的地方）的返回。我们必须从我们自己的 IResult 返回签名（这非常有用）转到似乎有问题的 IQueryable（但最终也可能有用）。

结果示例：
至少，我们的返回签名会发生巨大变化。而且，我被告知通过将“C Instance”更改为“IQueryable Instance”（这是有道理的）来实现 OData 的 WebAPI 调用不会起作用。

public interface IResult<C>
{
    [JsonProperty(PropertyName = "hasErrors")]
    bool HasErrors { get; }

    [JsonProperty(PropertyName = "errors")]
    IList<String> Errors { get; }

    [JsonProperty(PropertyName = "instance")]
    C Instance { get; set; }
}
4

1 回答 1

3

使用 Web API 支持 OData 查询不需要您拥有IQueryable<T>. 拥有一个IQueryable<T>可以让你用更少的代码更快地到达那里。IQueryable<T>具有将传入的 OData 查询转换为 LINQ 查询所需的抽象。该框架已经定义了它，并且它在各种后端都有丰富的支持，例如 Entityframework、NHibernate、Linq2Objects、RavenDB、Linq2OData 等。因此，我们决定对IQueryable<T>Web API 提供丰富的支持。同意，IQueryable<T>是一个巨大的接口，并且比 OData 查询所需要的要多得多。但这是免费的:)。

也就是说，我们ODataQueryOptions<T>对非 IQueryable 案例有很好的支持。在这里查看我的博客文章

此外，您将 OData 查询语义与 OData 混淆了。丰富的查询支持只是 OData 的一部分。OData 建立在 HTTP 之上，并具有各种有用的功能，例如

  • REST 和 HTTP 最佳实践的深思熟虑的应用程序。
  • 在 json 和 xml 中明确表示您的资源。
  • $元数据。
  • 描述关系的标准方式。
  • 支持投影、过滤、客户端驱动分页和服务器驱动分页（下一页链接）的丰富查询。
  • 大生态系统。
于 2013-03-13T20:47:55.837 回答