4

Azure Caching を直接使用します (使用可能な Entity Framework ラッパーの 1 つを使用するのではありません)。どうやら、分散キャッシュの場合、オブジェクトをシリアル化する必要があります。残念ながら、これにより、ナビゲーション プロパティに使用される遅延ロードされた DbContext ベースのプロキシで問題が発生します。

プロキシを空のコレクション (ロードされていない場合) または通常のオブジェクト (ロードされている場合) にマップするために、カスタムシリアライザーを使用できるようですが、実装についてはわかりません。考えられる実装の 1 つは WCF で使用される実装に基づいている可能性がありますが、Azure が同じように機能するかどうかはわかりません。

理想的な解決策 (そしてそれが ProxyDataContractResolver を指す理由です) は、シリアル化が発生したときに次のようなものになります。

  • ナビゲーション プロパティが既に読み込まれている場合、データは通常のコレクションのようにシリアル化されます。
  • それらがロードされていない場合、それらはシリアライズされません（後者の場合、デシリアライズ後に遅延ロードが機能することを望みますが、そうでない場合は許容されます）。

エレガントな方法でその問題を手動で修正した人はいますか?

前もって感謝します！

4

2 に答える 2

2

EFオブジェクトをキャッシュする場合は、それらのエンティティで遅延読み込みや変更の追跡を行う必要はないと思います。

これらは両方とも、シリアル化の問題を引き起こすオブジェクトプロキシを介して有効になっていると思います（プロキシをシリアル化したくないため）。

プロパティDbContext.Configuration.ProxyCreationEnabledを無効にすると、プロキシではなく実際のオブジェクトのシリアル化が正常に機能するはずです。これは通常、WCFを介してPOCOオブジェクトを返す場合に必要ですが、このような他のシリアル化シナリオでも同じです。

于 2013-01-12T00:26:18.637 に答える
1

シリアル化する前にEFエンティティをDbContextからデタッチすると、遅延読み込みが無効になるため、カスタムシリアライザーは、エンティティのグラフにまだ含まれていないものをシリアル化しようとしません。

次に、キャッシュから取得したときに、新しい（同一の）DbContextにアタッチすると、遅延読み込みが再度有効になります。

（警告：エンティティをコンテキストから切り離すと、同じオブジェクトを含む新しいクエリは新しい添付されたコピーを作成するため、異なる可能性のある複数のバージョンで問題が発生しないように注意してコーディングする必要があります同じオブジェクトが走り回っていますが、そうは言っても、これでやりたいことができるはずです。）

于 2013-01-14T14:06:36.207 に答える