MVVMデザインパターンを使用してSilverlightアプリケーションを作成しようとしています。それは銀行のアプリケーションの一種です。MVVMデザインに関する質問
私はMVVMに関する多くのチュートリアルを見ましたが、何かが私を本当に混乱させます。
"TransactionsView"、 "AccountView"など、ユーザーのパスワード、ユーザー名、UserAccountsのリスト、 "UserAccounts" - 名前、残高、およびAccountTransactionsのリスト、 "AccountTransactions" - 名前とammountを含んでいます。
私のuserprofileを含むmodelviewを1つ作成する必要がありますか、または私が持っているビューごとにviewmodelを作成する必要がありますか？私はこれまでにやっているの？それとも、私はそれが間違ってcompletleyを持っている？
ありがとうございました
MVVMでは、ViewModelsは通常、Viewsに1対1です。しかし、ViewModelとModelsの間にはパリティはありません。
ビューは常にViewModelを必要とするため、1対1（サブモデルを持つこともできますが、それを決めるために残しておきます。 〜1）。
ViewModelには実際には「仕事をする」ためのモデルが必要ですが、解決しようとしている各アプリケーション/問題までいくつのクラス/インスタンスが必要ですか。
2つの異なるビューに同じViewModelを使用できますか？また、他のビューモデルのパブリックプロパティを保持するグローバルな "MainViewModel"を用意して、どこからでもアクセスできるようにする必要がありますか？ – Richard
@リチャード：あなたが望むことは何でもできる、それはあなたのアプリです:)それはあなたのUIとあなたのプログラムの間の大使としてViewModelを考えています。プログラムをプログラムの観点から考えさせ、UIをUIの観点から考えさせ、ViewModelを翻訳させます。 UI状態/ UIコマンドを直接処理すること、UI入力の検証を行うこと、プログラム状態をUIに戻すことから離れすぎると、おそらくViewModelの国からモデルタウンに向かうでしょう。アプリのデザインの一部を見ることなく、私はもっと具体的な助言をすることはできません。 –
@リチャード：しかし、MVVMはあいまいです。あなたは1対1を持つ必要はありません。それは始めるだけの良い場所です。私は個人的には、ViewModelをもっと「ダム」にして、プログラムの流れをモデルの一部で指示させることを好みます。他の人は、プログラムの流れをViewModelの手に置きます。これは、あなたがしたいと思うようなものです。プログラミングが簡単で、理解しやすく（できるだけコメントを置いていない）、デバッグ/テスト/確認が容易で、バグがなく、保守が容易であれば、あなたはあなたがいることを知っている正しい道。 –
MVVMでは、ビューごとに1つのViewModelが推奨されます。
実際のハードとファーストのルールはありませんが、基本的にViewごとに1つのViewModelがあります。ビューモデルを複数のビューに共有したいという状況に陥ることはありますが、それはまれです。
画面上で見たいものと画面上の画面/コントロールがある状態を想像してみてください。特定の画面（ビュー）で必要なものはすべて、ViewModelでバインドできる対応するプロパティを持つ必要がありますへのビュー。したがって、これは特定のビューの単一のViewModelに変換されます。 ViewModel自体は、背面の1つまたは複数のモデルに結び付けることができます。少なくともそれは私がそれを理解する方法です。
便利なヒント：a）ビューモデルはビューのサーバントです。ビューのニーズに基づいて作成します。 b）モデルは非常にゆるやかに定義されていますが、これはほとんどの場合、データを読み込み/保存するためにビューモデルによって使用されるもの、およびビジネスロジッククラスです。 c）ビューモデルは、ビジネスロジック（例えば、検証規則）を含むこともできる。 d）モデルを軽量に保ち、それをやり直してはいけません。ビューとビューモデルは重要な部分です。 e）データバインディングとICommandを使用してビューとビューモデルを結合する。ビューからビューモデルへの直接的なメソッド呼び出しを最小限に抑えます。 – Sander