WPF – nibuiroフラグメント β

【WPF】【戯言】この私が…

【WPF】【戯言】この私が…

 「’mainwindow.xaml’ をプロパティ ‘StartupUri’ に割り当てることができません。値が有効な範囲にありません。」
 …Umm. 名前は変更していないのだけどねぇ。App.xamlを確認しても文字列は間違っていない。
ネットでググってちらほら出てくるようなありふれた原因ではないのか。フっ、この私が…愚民共と同じと思うなよ!?Google殿!!

 ま、まぁ完全一致ではない(汗)。
 MVVMフォルダ構成に整理したため「StartupUri=”View/MainWindow.xaml”」なのだよ。

終幕っ!!!

MVVM on WPF

MVVM on WPF

View

  • Modelの公開しているデータとコマンドを操作しやすいようにViewをつくる

 UIのことでありXAMLで記述される。Datacontextにクラスを指定してリソースとして利用するなどする。またCommandをバインディングする、ホットキーのバインドなどもxamlに記述される。viewが「UI/UXについて」、と考えればここでホットキーがバインドされることになんら問題はない。

Model

  • WPFで組んでいるものをFormsに変更することになると考えた場合に、変わらない部分をまとめるとモデルになる。

 a.k.a.エンジンで良いのではないかと。
 入力の検証はViewが変わったとしても変更されるわけではないのでModel側。Modelは変更通知機能を有することが許されていて、View側がModelからデータを直接受けとることはタブーではない。

ViewModel

  • ModelとViewで合わない部分を合うように変換する機能を作るとViewModelになる

 INotifyPropertyChanged、Command(ICommnad)などは基本的にここの枠組みに実装する。難読化が懸念されるほどのコマンド量が想定されれば適切な粒度で分類してファイルに分ける。Modelを継承したクラスに機能を追加してViewModelとしてもいい。役割はView専用の保持データの管理だと広く認知されている。ViewによってはModelに直接接続できない部分の変換を行う。言い換えると、View専用の表示に合うようにデータ整形する。逆に入力をModelに合うように整形する。
 表示することが目的のアプリの場合はページそのものがモデルで管理されるデータであるからViewModelでは管理しない。

識者によると、

「VMが注目されすぎて、Modelに実装すればいい機能までVMに実装してしまって、VMにMが混ざってしまうのが混乱する原因だと思う。」

「「Modelを継承してViewModelにしてやれば違いを意識せずに使えるよね」「後でVMにするならModelにINotifyPropertyChangedを実装してしまえ」という実装が楽ちんなのでよくやります。」

とのこと。