次のスタックを使用して新しいアプリを開発しています。
SQL Server 2008 R2 -> Entity Framework 4.2 -> WCF データ サービス -> WCF データ サービス クライアント ライブラリ
これはすべて.NET 4.0です
現在、WCF Data Services クライアント ライブラリは、少量のデータや単純なスキーマ/オブジェクト グラフには非常に便利ですが、より複雑なモデルには向いていません。特に、DataServiceContext.Links コレクションは O(n^2) のようにスケーリングすることがわかりました。ロードする関連オブジェクトが多いほど、グラフがネストされているほど遅くなり、データのロードに時間がかかります。ネットワークから読み取るよりもコンテキストに入れます。
たとえば、2000 メンバーのコレクションがあり、各メンバーに 4 つのナビゲーション プロパティがあるとします。ナビゲーション プロパティを展開せずにコレクション全体をプルするには、約 1 秒かかります。4 つのナビゲーション プロパティをすべて展開するには 5 秒かかります。スタックのさまざまなポイントでパフォーマンスを測定しましたが、余分な時間の大部分はクライアントで費やされ、データが照合されました。
大規模なデータセットでこれを回避するために、さまざまな手法を採用しています。
- 非正規化。これは、常に展開するグラフに適しています。グラフの一部の読み込みを遅らせたい場合は、うまく機能しません。
- 関連するオブジェクトを個別にロードし、データ コンテキストの外でそれらをつなぎ合わせます。これは面倒ですが、context.Links の問題を解決します。
- 複数のデータ コンテキストを使用して、Links コレクションへの負荷を最小限に抑えます。
- (1) & (2) に接続して MergeOption.NoTracking を使用する
他のテクニックを知っている人はいますか？関連オブジェクトをロードするときに不要なオーバーヘッドを引き起こしている可能性のある設定はありますか?
独自のカスタム コンテキストを作成する途中のように見える場合があり、これ以上複雑になる前にサニティ チェックを行いたいと思います。
[はい、WCF Data Services がこの仕事には不適切なツールである可能性があることは認識しています。残念ながら、私たちはすでにその道を進んでいます]