使用 OData 是不是一个好主意？

Question

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

从外观上看，OData compliant signatures require you return IQueryable。

举例：

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

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

• Leaky
• 'Causing Heavy Lifting' 示例：允许用户抓取整个表格
• allows for heavy modification 查询本身存在安全和扩展问题
• 也可能导致延迟执行问题（因为它的可查询性质）

我的问题是：
您是否觉得 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; }
}

Answer 1

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

也就是说，我们通过ODataQueryOptions<T> 为非 IQueryable 案例提供了良好的支持。查看我关于此here的博客文章

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

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