Windows Formから、WPFのコードビハインド。次に、MVVMを学んでコードを書いています。
MVVMについての感想を、つらつら書きます。
#MVVMで苦労している点
- 例えると、コードビハインドでは、（右利きの場合）右手にペンをもって、左から右に文字を書いていたけれども、MVVMでは、左手にペンをもって右から左の逆の順に文字を書いているようなものになった。
- 例えると、コードビハインドでは、図と解説を、1枚の書類に収めれば良かったが、MVVMでは、図と、解説と、図と解説との間を繋げる書類の、3枚の書類が必要になった。
- コードビハインドは、データの流れが一方通行でデバッグ時追跡しやすかったが、MVVMでは、データがどこに流れているのか追跡しにくい。
- コードビハインドでは1行で済むのを、MVVMの方法に合わせるために5行も10行もそれ以上にコードを書かないといけない場合がある。
と、ここまで、デメリットを書きましたが、メリットも実感しています。
#MVVMで感じるメリット
- WPFでは、データバインディングを利用するため（しなくてもいいが、した方が楽）、Viewで表示するためのプロパティを1カ所に集めるのは合理的。従って、Viewで利用するプロパティを、1つのViewModelに集約して、1対1の関係にしてしまう、のは分かりやすくなる。特に、ListViewやDataGirdで表示するデータを1行ずつ、VMにしてからListViewやDataGridにバインドする場合は、都合が良い。
- Viewと、ViewModelはパターン化できる。従って、後で見返したときも、理解しやすい。
#その他
- View, ViewModel, Modelの役割を明確に分けることで、パターン化できるが、ViewModelの役割をよく考えてコードを書かないと、Modelの領分を侵してしまう。どこまで、ViewModelの役割にするのか、考える必要がある。
- ListViewの1行ずつを、ViewModelにする方法は、よくあるMVVMの関係を示す図からは、想定できない。
- MVVMを実現するためのコードの書き方が、考え方の差によるバラツキが大きい。
例えば、Viewのコードビハインドで、イベントをキャッチして、それを、VMに渡す、というのでも、VMからはVは疎結合のままなので、良いという考え方もある。
#現時点
- 学習コストが高い
- MVVMを実現するためのフレームワークもツールもまだまだ足りない、不便。
- ネットのMVVMのサンプルや解説はどれがお手本として適切なのか見極めるのが難しい
- 大規模なアプリなら、MVVMで構築した方が、その後の機能追加や、修正を行いやすくなると思う。
- 小規模なアプリなら、開発効率は低下する。