OData、Web Api 2 和深度嵌套对象答案

【问题标题】：OData, Web Api 2 and deeply nested objectsOData、Web Api 2 和深度嵌套对象
【发布时间】：2014-03-22 09:43:18
【问题描述】：

我一直试图找到这个问题的答案，但没有任何运气。假设我有一个看起来像这样的模型：

public class A
{
    public int Id {get;set}
    public ICollection<B> Bs {get;set;}
}

public class B
{
    public int Id {get;set}
    public ICollection<C> Cs {get;set;}
}

public class C
{
    public int Id {get;set}
    public string Something {get;set;}
}

我可以编写一个 Web Api 2 OData 控制器，同时可以像这样查询： /odata/A(1)/B(2)/C(3)/某事

如果这是多余的，请指出我应该看的地方。谢谢！

【问题讨论】：

标签： c# entity-framework odata asp.net-web-api2

【解决方案1】：

自定义路由约定部分可以查看http://www.asp.net/web-api/overview/odata-support-in-aspnet-web-api/odata-routing-conventions。希望这能解决您的问题。

【讨论】：

【解决方案2】：

（这是一篇旧文章，但它缺少对 OData 新手开发人员这个标准问题的关键回答）

如果这是多余的，请指出我应该看的地方

是的，当 C 类上的 Id 属性是唯一的时，这样的 URL 路由是多余的。您正在操作的资源是 C 的一个实例，因此在 C 资源上执行 Something 操作的默认 v4 方式是直接调用 C 资源：

~/odata/C(3)/Something

如果您在CController 上定义Something 操作，则根本不需要任何自定义ODataRouteAttribute。 A 和 B 的键应该是冗余的，并且可以从 C 对象中发现。这与许多其他基于 Repo 的 API 模式不同，但对于支持我们获得 OOTB 的标准路由和约定很重要。

虽然您可以编写自己的 URL 路由以匹配您的预期模式，但括号是 OData v4 路由约定中的特殊约定，用于指示要操作的特定项目的键或 URL 参数传递给函数调用。

请记住，通过故意实施自定义路由，您将难以让符合标准的客户端与您的服务进行交互，在大多数情况下，采用 OData 的驱动力是提供符合标准的 API。

如果您真的想要这样的网址，那么我建议您删除()：

[ODataRoute("A/({key})/B/{bKey}/C/{cKey}")]

然后您可以将其定义为A 控制器上的绑定操作，除了标准的key 参数外，该控制器还具有bKey 和cKey 参数。

【讨论】：

【解决方案3】：

如前所述，添加常规规则以支持深度导航的一种方法。在 OData V4 中，您应该能够使用属性路由来支持您的 URL。向控制器添加 Route 注释，如下所示：

[ODataRoute("/A({key})/B({key})/C({key})")]

请注意，官方 webapi V4 支持将于 6 月推出。

【讨论】：