リスト ページから詳細ページに移動する場合、ページ間で選択データを渡すには、ビュー モデル インスタンスを共有する方法と、ナビゲーション Uri のクエリ文字列で識別子を渡す方法の 2 つの高レベルの方法があります。
どちらを使用する必要がありますか? あるアプローチを他のアプローチよりも使用することに問題はありますか (ビュー モデルからの現在の Uri へのアクセス、ナビゲーション イベントのタイミングなど)。
リスト ページから詳細ページに移動する場合、ページ間で選択データを渡すには、ビュー モデル インスタンスを共有する方法と、ナビゲーション Uri のクエリ文字列で識別子を渡す方法の 2 つの高レベルの方法があります。
どちらを使用する必要がありますか? あるアプローチを他のアプローチよりも使用することに問題はありますか (ビュー モデルからの現在の Uri へのアクセス、ナビゲーション イベントのタイミングなど)。
個人的には、ナビゲーション URI クエリ文字列の一部として識別子を渡すことをお勧めします。これらの URI は、トゥームストーン処理後にアプリケーションが再度有効になったときにバックスタックを形成するために復元されます。
廃棄後にアプリケーションが復元されると、アプリケーションのビュー モデルをアプリケーションの状態から再作成し、URI クエリ文字列を使用して、新しく作成したビューを必要な DataContext と「結合」します。
ここで実際の例を参照してください。
http://www.scottlogic.co.uk/blog/colin/2011/05/a-simple-windows-phone-7-mvvm-tombstoning-example/
2つのアプローチは非常にうまくいっています。
本当の違いは、廃棄プロセスにあります。
アプリケーションに戻ると、オブジェクトの ID が解析されます。
共有ビューモデルを選択した場合は、ナビゲートするときに ID を保存する必要があります。
この 2 つの組み合わせが最適なようです。queryString を使用して移動し、sharedViewModel を使用するため、新しいページに移動すると、queryString から ID を取得し、その ID を持つ sharedViewModel からデータを取得します。
SharedViewModel を管理してデータを IsolatedStorage に保存し、廃棄されたときに Web で読み込まれたデータを復元できます