私はこれを数日間苦労しており、問題がシリアル化の問題にまで孤立していると思います。複雑な型を返すWCFデータサービスは、ATOM形式ではありません
私はWCFデータサービスを持っており、データセット（n個の行）を取得するストアドプロシージャを呼び出しています。データサービスは関数インポートを使用しており、複合型を返します。サービスは、ブラウザで次のように返します正常に動作します：
<にGetChangesののxmlns = "http://schemas.microsoft.com/ado/2007/08/dataservices" >
<要素のxmlns：P2 = "HTTP ：//schemas.microsoft.com/ado/2007/08/dataservices/metadata」P2：タイプ= "tasksModel.fxGetChangeList_Result" >
<CHANGE> DELETE <は/ CHANGE >
< IDのP2：タイプ= "Edm.Int32"/ID >
< UpdateVersionのP2：タイプ= "Edm.Int64"/UpdateVersion >
< /要素>
< /にGetChanges >
しかし、私このデータをクライアント（Windowsの電話アプリ）から呼び出すと、結果は返されません。私は、URLが直接上記のデータを引き下げていることを確認しました。ここで
は、クライアントのコール...
_changes.LoadCompleted += new EventHandler<System.Data.Services.Client.LoadCompletedEventArgs>(Items_LoadCompleted);
_changes.LoadAsync(new Uri(theUrl, UriKind.Absolute));
そして、ここでは、コールバック
void Items_LoadCompleted(object sender, System.Data.Services.Client.LoadCompletedEventArgs e)
{
int count = _changes.Count;
_changes.ToList().ForEach(x=>{
....
});
であるエラーが何も結果が返されません単にスローされません。
データサービスの上記のxmlがアトム形式ではありません。私が考えることができるのは、クライアントがAtom形式ではないため、複雑な型のデータをシリアル化できないことだけです。
私は3つの質問があります： 1.他に誰かがこれに遭遇しましたか？ 2.複合型をシリアル化するクライアントの回避策はありますか？ 3.コンプレックスをAtomにシリアル化するサーバー側の問題はありますか？
ありがとうございました。私はデバッグするのにもっと多くの時間を費やしていたでしょう。一般に、私は、クライアントの行動を学び、プロトコルの多くに従わなければならないことが、その価値よりももっと努力していることを見出しています。私は時間をデバッグするためのコードを書く時間を代用しています。 ほとんどの場合、webHttpBindingsを使用して非データサービスWCFサービスを公開し、そのようにオブジェクトを公開するほうがよいと思います。私は、ペイロードのサイズをより細かく制御し、送信される実際のオブジェクトをより詳細に制御します。 主な使用例は、SQL AzureデータをWebクライアントおよびモバイルクライアントに公開することです。私は何か見落としていますか？ – frigon
あなたの要件に大きく左右されます。 OData（WCF DS）は、クライアントが事前にわからない質問をする能力が必要な場合に最適です。クライアントから質問されることが分かっている場合は、OData以外のWCFサービスで行うことができます。一方、ODataでは、特定のビジネスロジックを実装するのが難しい場合があります.WCFは通常より簡単です。したがって、サービスをクライアントに結びつけ、両方を制御し、サーバー上でクエリをハードコードすることができれば、単純なWCFサービスが機能します。クライアントに自由が必要な場合は、ODataが必要になります。 –