私はその質問を理解していると思います。私はマルチマネージャーアプローチを使用すると思います：
- Lookups Manager-セッションごとに1回の参照（ルックアップ）エンティティを保持します
- JobsViewManager-JobsViewをサポートするジョブの「読み取り専用」リスト
- JobEditorManager-編集セッションごとに1つ。
Lookups Managerは、参照エンティティの正規のコピーを維持します。サーバーへの1回の呼び出しで1回入力できます（方法については、ドキュメントを参照してください）。このルックアップマネージャーは、これらの参照エンティティを他のマネージャーにBreezeエクスポートし、作成時にBreezeインポートします。私は、多数の多様なものの、参照エンティティの合計メモリフットプリントはかなり低いと想定しています...複数のマネージャに複数のコピーを持つ余裕があるほど十分に低いです。そうでない場合は、より複雑な解決策があります。しかし、それは今のところです。
JobsView Managerには、表示に必要な参照エンティティがあります。ジョブの予測のみを表示した場合、キャッシュにはジョブがありません。代わりに、配列とキーマップがある場合があります。シンプルに保ち、すべてのジョブが含まれているが、関連するエンティティは含まれていないと仮定しましょう。
このマネージャーで変更を保存することはありません。ジョブを編集または作成するとき、アプリは常に独自のVMとJobEditorManagerを備えた「ジョブエディター」ビューを起動します。ここでも、必要な参照エンティティをインポートし、既存のジョブを編集するときに、ジョブもインポートします。
私はとにかくこのアプローチを取ります...メモリの問題だけではありません。編集セッションをサンドボックスに分離するのが好きです。キャンセルを容易にします。アプリ/ブラウザーがダウンした場合にユーザーが作業を失うことがないように、ブラウザーのストレージに保留中の変更を保存するためのクリーンな方法を提供します。複数のジョブを同時に編集するための扉を開きます...変更のある相互に依存するエンティティについて心配する必要はありません。これは、SLアプリで永遠に使用されてきた実証済みのパターンであり、JSアプリにも適用されるはずです。
ジョブの編集が成功したら、ローカルクライアントの世界にそのことを伝える必要があります。それを行う方法はたくさんあります。知る必要がある唯一の場所がJobsViewである場合は、アプリにバックチャネルをハードコーディングできます。もっと賢くなりたい場合は、特に仕事の節約に関するイベントを発生させる中央シングルトンサービスを利用できます。JobsViewと新しい各JobEditorは、このサービスと通信します。そして、ヒップになりたい場合は、この目的のためにインプロセスの「イベントアグリゲーター」（パブ/サブ）を使用します。とにかくこのアプリにはおそらくDurandalを使用していると思いますが、ボックスにはイベントアグリゲーターが含まれています。
正直なところ、使用するのはそれほど複雑ではなく、マネージャー間でエンティティをインポート/エクスポートするのは...エム...簡単です。ジョブリストに戻るたびに更新するのと比較すると、それだけの価値があります（ただし、他のユーザーがそれらのジョブを追加/変更する可能性があるため、「更新ボタン」も必要になります）。クエリ、検証、変更の追跡、バッチ保存、エンティティナビゲーションなど、Breezeの多くの利点を保持します（これらの参照リストはBreezeでは「無料」で機能します）。
改良点として、JobsViewに戻ったときにJobEditorビュー/ビューモデル/マネージャーを自動的に破棄するかどうかはわかりません。私の経験では、人々はしばしば彼らが去ったばかりの同じ仕事に戻ります。あなたが素早く行き来できるように、私は眺めを保持するかもしれません。しかし今、私はトリッキーになっています。