ここで記事を読んでいました https://azure.microsoft.com/en-in/documentation/articles/service-fabric-work-with-reliable-collections/ "信頼できるコレクションに与えたらオブジェクトを変更してはいけません。サービスファブリックの信頼性の高いコレクションと不変性
なぜそうですか？オブジェクトを変更して信頼性の高いコレクションに追加することはできませんか？それは以前の値を上書きしませんか？
完全な声明がある：あなたが信頼性の高いコレクションにそれを与えている 一度あなたがオブジェクトを変更してはいけません：
しかし、信頼性の高いコレクションで、このコードは、すでに説明したのと同じ 問題を呈します。
この文は、信頼性の高いコレクションの作業に関連する問題の背景にあります。 SFの信頼性の高い辞書で作業する場合、APIは標準の.NET辞書のように見えます。舞台裏では、国家の管理のようにやっています。このような差別化を実現するためには、これらのデータ構造を扱う際に共通の落とし穴に留意する必要があります。最初のコードのデモンストレーションでは、オブジェクトを更新するように見えますが、そうではありません。記事の後半では、信頼できるコレクション内のオブジェクトを修正する正しい方法を提供しました。
同じオブジェクトを修正し、信頼性の高いコレクションに書き戻すことができます。しかし、このアプローチはバグです。オブジェクトを変更すると、値はローカルでのみ変更され、プライマリとセカンダリの複製のディスクには書き込まれません。明示的に変更されたオブジェクトを信頼できるコレクションに書き戻すまで、オブジェクトと永続コピーのローカルコピーは同じではありません。したがって、オブジェクトを不変として扱い、オブジェクトのディープコピーを変更することは、常に良い習慣です。
伝統的な.netコレクションでは、ディクショナリ（またはキューのpop/peek）内のキー付きルックアップのValueは、ヒープ上のオブジェクトへのポインタを返します。このポインターを変更すると、ヒープ内の値が変更されます。その結果、状態は辞書内で突然変異される。
信頼性の高いコレクションは、はるかに複雑な相互作用を取り巻くファサードです。コレクションがメモリ*内にあることは真実ですが、信頼できる状態マネージャーもセカンダリレプリカへの変更の複製を担当します。これが発生するメカニズムは、ITransactionでCommitAsyncを呼び出すことです。
オブジェクトのメモリ内表現を変更するだけの場合、変更はセカンダリパーティションに複製されず、未定義/予期しない動作が発生します。 （アクティブプライマリがセカンダリに切り替わるとき）CommitAsyncを呼び出すと（Get - > Modify - > Setを実行しても）トランザクションがコミットできず、現在のメモリ表現がセカンダリのものと異なるパーティションとプライマリパーティションのディスク上の表現です。これは、未定義/予期しない動作につながります。
*ほとんどの場合、コレクションのサイズが使用可能なメモリより大きい場合を除きます。この場合、値はディスクからページされ、キーと最近使用された値だけがメモリに保持されます。将来、ディスク圧が高まると、ブロブストレージにさらにページングすることについて話を聞いてきました。