2012-03-28 11 views
1

MVVMパターンSilverlightとXAMLで把握しようとしています。SilverlightでのMVVMデータの永続性

私はフレームにビューを読み込むメインページがある段階にあります。各ビューは、xamlのviewmodelにバインドしてから、viewmodelsデータにバインドできます。また、ボタンクリックやグリッドイベントなど(SelectionChangedなど)のコマンドを実行しています。

メインページのナビゲーションメニューを使用してユーザーがナビゲートすると、新しいビューがフレームに読み込まれ、独自のビューモデルのインスタンスが作成されます。

私の質問は、1つのビューのための私のviewmodelは、いくつかのデータのWCFメソッドを呼び出し、viewmodelに保持されているObservableCollectionへのバインディングを介してグリッドでこれを表示します。変更が加えられた場合は、単にWCFの保存メソッドを呼び出し、このObservableCollectionを戻します。しかし、ユーザーがグリッド内の行をダブルクリックすると、情報をいくつか保存して次のビューに保持する必要があります(ダブルクリックも別のビューに変更されるため)。 「選択したアイテムID」のような情報

私が結んだのは、ビューモデルから分離し、アプリケーションの状態やユーザーの選択などを保持するクラスの「モデル」セットです。ビューモデルは、ここでは「選択したアイテムID」のように物を保存できます。私の考えでは、「モデル」はWCFコールの反対側にあるすべてのものでした。ここで別のモデル「レイヤー」を作成する必要があるとは思わなかったのですか?

私はこのアプローチで何が間違っているのか分かりませんが、間違っています。

私はこれをどのようにしなければならないかについて誰かに光を当てはめることができますか?または、これがokのアプローチであれば?私はここでパターンを誤解していますか?

ありがとうございました!

答えて

0

ワークフローがある場合、1つのビューモデルで '選択'を設定し、後でこの値を消費するビューモデルを知っている場合、おそらくEventAggregatorアプローチを使用して、必要なパラメータを使用して別のビューモデルにイベントをパブリッシュできますこの値をどこか別々に保存する。

+0

しかし、情報を知る必要があるビューモデルはまだインスタンス化されていませんか?これは、フレーム内のビューがビューxamlを介して変更された場合にのみ発生します。 – creatiive

1

私はあなたがそれを考えていると思います。私はこれが大丈夫だと思う。私はそれが合理的に "UIモデル"を持っていると思います。すべてのアプリケーションには通常、ヘルパークラスがあります。あなたが「懸念の分離」アプローチを取っている限り、あなたのアプリは維持可能になります。私のSilverlightアプリケーションには、必要に応じてアプリケーションの状態を追跡する「モデル」領域があります。このモデル領域には、UI固有のクラスもあります。 - 私の2セント。