c# - 使用 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，后者似乎有问题(但最终也可能有用)。

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

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 等。因此，我们决定对 IQueryable<T> 提供丰富的支持。使用网络 API。同意，IQueryable<T>是一个巨大的接口(interface)，公开的内容远远超过 OData 查询所需的内容。但它是免费的:)。

也就是说，我们通过 ODataQueryOptions<T> 获得了很好的支持对于非 IQueryable 情况。查看我关于此的博客文章 here

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

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