1

正如我在上一个问题中提到的，我阅读了 Alex D. James 的优秀的三年前的 WCF 数据服务自定义提供程序博客。当我进入有关相关数据的部分时，我们盲目地将所有数据描述为ResourceTypeKind.EntityType. 我查了文档，没有关于使用的定义或指导ResourceTypeKind.ComplexType。

我假设它是一种始终包含在我的查询中的非原始类型，但找不到任何可以证实这一点的东西。这将是用于 EF 的模型。我认为这就是为什么它甚至存在的原因。

如果我的假设是正确的，我是否ComplexTypes以与我相同的方式定义 my ResourceTypeKind.EntityTypes？我可以为 WCF 数据服务 ComplexTypes 假设与 EF ComplexTypes 相同的规则吗？

[编辑]跨 WCF 数据服务（又名 OData）进行查询有什么影响？我应该使用 .Expand(complex) aka $expand 吗？在使用 LInQ 和 WCF 数据服务客户端的客户端中，我是否应该创建匿名类型以获取复杂类型？客户是否知道他们是 ComplexType？

4

1 回答 1

2

OData 中的复杂类型与 EF 中的复杂类型非常相似。通过 OData，它们被视为原子“值”类型。所以响应总是包含整个值（即使它是嵌套的，即在层次结构中包含多个复杂类型等等）。

至于查询支持，客户端只有在请求单个值时才能寻址到复杂类型。（假设 Address 是 Customer 的一个属性，类型是复杂类型）。因此，例如 ~/Customers(1)/Address/City 是一个有效的查询，它只返回 Address 复杂值的 City 属性。

由于该值被视为原子值，因此 $expand 对其不起作用（它将失败，因为它仅适用于导航属性）。$select 确实有效，但仅适用于整个复杂属性。所以我可以做 ~/Customers?$select=Address 这将返回我所有的客户，但只有 Address 属性。我不能做 ~/Customers?$select=Address/City - 这是无效的。

以某种方式，您可以将复杂属性视为“始终扩展”，但最好不要将它们视为实体/导航，而是将它们视为单独的事物。

于 2013-02-04T10:29:51.617 回答