1

前回の質問で述べたように、私はAlexD.Jamesの優れた3年前のWCFデータサービスカスタムプロバイダーのブログを読んでいます。関連データに関するセクションにたどり着くと、すべてのデータをやみくもに説明しますResourceTypeKind.EntityType。ドキュメントを調べましたが、の使用に関する定義やガイダンスはありませんResourceTypeKind.ComplexType。

常にクエリに含まれるのは非プリミティブ型であると思いますが、それを確認するものは見つかりません。これはEFに使用されるモデルになります。それがこれが存在する理由だと思います。

私の仮定が正しい場合、私は私ComplexTypesがするのと同じ方法で私を定義しますResourceTypeKind.EntityTypesか？WCF Data Services ComplexTypesについて、EF ComplexTypesと同じルールを想定できますか？

[編集] WCFデータサービス（別名OData）全体でクエリを実行することにはどのような影響がありますか？.Expand（complex）別名$ 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 に答える