DataServiceCollection を使用してデータを取得し、Silverlight で OData を操作しています。
データをフェッチするためのすべての呼び出し (LoadAsync() LoadNextPartialSetAsync()) は、ワーカー スレッドで行われます。ただし、「LoadCompleted」コールバック、逆シリアル化、およびオブジェクトの実体化は UI スレッドで行われます。
DataServiceCollection がある System.Data.Services.Client.DLL を逆コンパイルしたところ、OData の応答を処理するすべてのコードが UI スレッドにディスパッチされていることがわかりました。
代わりに、逆シリアル化をワーカー スレッドで呼び出す方法はありますか?
ありがとうヤロン
良い...
OData コレクションは、UI スレッドの処理を意図的に移動しているようです。古いオブジェクトにはUIがバインドされているプロパティがある可能性があるため、これが行われたと思います。これらのプロパティは、追加データをロードするときに変更される場合があります。
クエリ自体を使用して、ワーカー スレッドで応答を取得できました。ただし、これを行うと、UI がプロパティにバインドされている場合、オブジェクトを OData コンテキストから切り離す (または複製する) 必要があります。そうしないと、オブジェクトがワーカー スレッドで具体化されているときに、結果のクエリによってプロパティ変更イベントが発生する可能性があります。
あなたが持っている問題は、DataServiceCollection<T>がから派生しているということObservableCollection<T>です。これは、UI要素にバインドされるように設計されています。ObservableCollection<T>バインディング式のメンバーシップに変更が加えられると、それを監視して通知されます。次に、このバインディング式は、ターゲットUI要素の更新を試みます。通知がUI以外のスレッドに到着すると、例外が発生します。
したがって、DataServiceCollection<T>意図的にマテリアライゼーションをUIスレッドにシフトして、アイテムがコレクションに表示されたときに、結果として生じる変更通知が例外にならないようにします。この振る舞いがあなたに受け入れられない場合は、あなたにDataServiceCollection<T>は向いていません。
代わりに、を介して自分でクエリを実行してくださいDataServiceQuery<T>.BeginExecute。渡すコールバックBeginExecuteはワーカースレッドで実行されます（少なくともClientHTTPが使用されている場合は実行されますが、XmlHttpが使用されている場合に何が起こるかはまだ確立されていません）。ここでは、結果を列挙して、好みのコレクションタイプに配置できます。結果を表示する準備ができたら、UIスレッドに切り替えることができます。
コールバックは常に UI スレッドで呼び出されます。要求が XmlHttp スタック (UI スレッドから呼び出す場合の既定) を使用していた場合、ネットワーク スタックは、UI スレッドで WCF データ サービスによって登録されたコールバックを呼び出します。したがって、この場合は DataServiceCollection/DataServiceContext の動作ですが、基盤となるネットワーク スタックの動作です。非 UI スレッドからリクエストを呼び出すか、明示的に Http スタックをクライアントに設定すると、コールバックは非 UI スレッド (潜在的に別のスレッド) に返されます。呼び出し元に知らせる前に、UI スレッドに戻します。この理由は、特にバックグラウンド スレッドで UI 要素を操作できないため、一貫性にあります。
たとえば DataServiceContext.BeginExecute を使用してクエリを手動で実行する場合、呼び出しはまだ入力されていない IEnumerable のみを返すため、実体化 (またはそのほとんど) は呼び出し元によって駆動されます。次に、実行をワーカー スレッドに転送し、そこで結果を列挙すると、そのスレッドで実体化が行われます。
ちょっと気になるのですが、なぜ動かしたいのですか？目に見える UI の遅延が発生するほど大量のデータを処理していますか?