WPFViewModelの公開しているデータとコマンドを操作しやすいようにViewをつくるUIのことでありXAMLで記述される。Datacontextにクラスを指定してリソースとして利用するなどする。Commandをバインディングする、ホットキーのバインドなどもxamlに記述される。viewが「UI/UXについて」、と考えればここでホットキーがバインドされることになんら問題はない。ModelWPFで組んでいるものをFormsに変更することになると考えた場合に、変わらない部分をまとめるとモデルになる。a.k.a.エンジンで良いのではないかと。入力の検証はViewが変わったとしても変更されるわけではないのでModel側。Modelは変更通知機能を有することが許されていて、View側がModelからデータを直接受けとることはタブーではない。ViewModelModelとViewで合わない部分を合うように変換する機能を作るとViewModelになるINotifyPropertyChanged、Command(ICommnad)などは基本的にここの枠組みに実装する。難読化が懸念されるほどのコマンド量が想定されれば適切な粒度で分類してファイルに分ける。Modelを継承したクラスに機能を追加してViewModelとしてもいい。役割はView専用の保持データの管理だと広く認知されている。ViewによってはModelに直接接続できない部分の変換を行う。言い換えると、View専用の表示に合うようにデータ整形する。逆に入力をModelに合うように整形する。表示することが目的のアプリの場合はページそのものがモデルで管理されるデータであるからViewModelでは管理しない。「VMが注目されすぎて、Modelに実装すればいい機能までVMに実装してしまって、VMにMが混ざってしまうのが混乱する原因だと思う。「「Modelを継承してViewModelにしてやれば違いを意識せずに使えるよね」「後でVMにするならModelにINotifyPropertyChangedを実装してしまえ」という実装が楽ちんなのでよくやります。