使用OData是一个好主意吗？

Question

提前了解"只是因为提供能力并不能使它成为一个好主意"的警告......

从外观上看,OData兼容签名要求您返回IQueryable.

例如:

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

然而,最近和不近期的许多文章都将IQueryable描述为:

• 漏
• " 导致重举 "的例子:允许用户抓住整张桌子
• 具有安全性和扩展性问题,因为它允许对查询本身进行大量修改
• 也可能导致延迟执行问题(因为它具有'可查询性)

我的问题是:
你觉得IQueryable和OData的能力超重了上述问题吗？

在回答中,我希望人们谈论:

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

...像这样的东西.

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

IRESULT示例:
至少,我们的返回签名会发生巨大变化.并且,我被告知WebAPI调用实现OData不会通过将"C Instance"更改为"IQueryable Instance"(这是有道理的).

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 查询所需的抽象。IQueryable<T>该框架已经定义了它，并且在各种后端（如 Entityframework、NHibernate、Linq2Objects、RavenDB、Linq2OData 等）都有丰富的支持。因此，我们决定通过 Web API提供丰富的支持。同意，IQueryable<T>这是一个巨大的接口，并且公开的内容远多于 OData 查询所需的内容。但这是免费的:)。

也就是说，我们ODataQueryOptions<T>对非 IQueryable 情况提供了良好的支持。在这里查看我关于此的博客文章

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

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