0

私は広範囲に検索しましたが、ODataLib を使用してサービス操作を呼び出す方法の良いサンプルやチュートリアルを完全に見つけることができませんでした。エンティティとエンティティ セットを取得する方法を教えてくれるものをいくつか見てきましたが、それは素晴らしいことですが、サービス操作を呼び出すためです。

ODataEntry、ODataFeedまたはODataNavigationLinkオブジェクト以外のものを使用する必要があることはほぼ確実です。ライブラリを JustDecompile で開いたところ、 や のようなクラスが表示ODataActionさODataFunctionれますが、それらの使用方法がわかりません。

私のニーズは非常に単純です。WCF Data Services 5.0 サービス操作を呼び出す必要があり、JSON を使用して実行する必要があります。

また、WCF Data Services Client ライブラリの今後のリリースで JSON がサポートされる予定であることも認識していますが、残念ながら昨日と同じようにコーディングする必要があります。さらに、必死になって、Mark Stafford の JSON ライト サンプルを使用して RC バージョン ( Gasp ) を実装しようとさえしましたが、それがどのように機能するかはよくわかりませんでした。

どんな助けや指示も大歓迎です！(特にこれが画面に表示されたら、マーク!)

ありがとう！J

4

2 に答える 2

2

ODataLibは、サービス操作の応答を読み取っていることを認識していません（認識していないはずです）。どのペイロードの種類を読みたいかが重要なのは唯一のことです。

これは、サービス操作が何を返すかによって異なります。単一のエントリを返す場合は、ワイヤ形式が同じであるため、単一のエントリのペイロード（たとえば、〜/ Products（0））を読み取るのと同じようにODataLibを使用します。サービス操作がエンティティのコレクションを返す場合は、フィードのように読み取ります。

サービス操作が単一のプリミティブ値または複素数値を返す場合は、ODataMessageReader.ReadPropertyを使用できます。メソッドの名前が少し誤解を招くことは知っていますが、これもプロパティペイロード（〜/ Products（0）/ Nameなど）とプリミティブ型または複合型を返すサービス操作がまったく同じペイロード形式を使用しているためです。この場合、返されたプロパティの名前は無視する必要があります（サービス操作の名前である可能性があります）。

サービス操作がプリミティブ値または複素数値のコレクションを返す場合は、ODataMessageReader.CreateODataCollectionReaderを使用できます。これにより、ODataReaderと非常によく似た方法で使用するODataCollectionReaderリーダーが返されます。それが報告する興味深いものは、問題のコレクションのアイテムです（この場合のAPIは非常に理解しやすいです）。

ATOMとJSONのどちらを読む必要があるかは問題ではありません。それはあなた次第です。APIは同じです。

于 2012-07-15T17:59:23.150 に答える
2

クライアントとして ODataLib と WCF Data Services (ODataLib に依存) のどちらを選択するかは、多くの場合、制御の必要性に帰着します。ユース ケースが単純で、最も一般的な機能が必要な場合は、おそらく WCF DS が適しています。高度な機能が必要な場合や、ペイロードの読み取り方法を正確に制御する必要がある場合は、ODataLib の方が適している可能性があります。とはいえ、Vitek は、ODataLib を使用してサービス操作を読み取る方法を概念的に説明しています。

WCF DS は、バージョン 5.1 で JSON Light の読み取りをより簡単にします。これについては今週中にブログに書きますが、参照したサンプルは、この RC で実行する必要があるものです。私がまとめたサンプルには、新しい呼び出しが 1 つだけありますcontext.Format.UseJson(Func<Uri,ModelResolverResult>)。まず、この呼び出しが必要な理由について話しましょう。OData (少なくとも Microsoft の世界では) は、強い型付けでうまく機能します。$metadataは、使用するデータ モデルを説明する OData の良い例です。Atom ペイロードまたは JSON Verbose ペイロードを使用すると、そのタイプ情報の多くがペイロードで運ばれました。JSON Light の目標は、「トランスポート」ペイロードからそのメタデータを可能な限り取り除くことでした。

メタデータが帯域内で使用できない場合は、帯域外で使用できるようにする必要があります。これは、 への呼び出しの署名の背後にある基本的な要件ですUseJson。基本的に、WCF DS がメタデータを必要とするときはいつでも、指定された URI のモデルを検索します。そのモデルが見つからない場合、最終的にメタデータを完全にダイヤルアップします。ペイロードが肥大化するため、これを回避したいと考えています。モデルを事前に解決する方法を WCF DS に指示することで、それを回避できます。これは、サンプルの大部分が行っていることです。

サンプルを論理的に見ていきます (はい、他にも多くの最適化が可能であることは知っています。サンプルは読みやすさのためにほとんど最適化されています)。

  • モデルが過去に解決されていない場合
    • XmlReaderへの呼び出しのために新しいを構築しますEdmxReader.TryParse
    • out パラメーターの値をいくつか挙げてくださいEdmxReader.TryParse
    • 呼び出すEdmxReader.TryParse
      • 呼び出しが成功した場合、解析されたモデルをローカル ディクショナリにキャッシュします (現在、解析はコストのかかる操作です)。
      • 呼び出しが失敗した場合は、エラーをまとめてスローします
  • キャッシュされたモデルから正しいモデルを取得し、ModelResolverResultラッパーで返します

うまくいけば、それは理にかなっています。そうでない場合は、ブログの投稿をより明確にするために、その理由をお聞かせください. そして、これらのビットを本番環境にリリースするまでに、これははるかに簡単になることを忘れないでください.

于 2012-07-16T15:22:24.507 に答える