前提

MVVMと聞いてもピンとこない人。MVCという名前は聞いたことがあるけど、中身が今一つ分かっていない人。アーキテクチャについて勉強したい人。設計を行う人など。

Modelってなんだろう？ViewModelって？

■MVC（Model,View,Controller）の場合

MVCにはViewModelはない。ModelにViewModelの機能が内包されているからだ。

では、MVCにおけるModelとはどういった役割を担うのか。

それは、ビジネスロジックを書く場所、となる。Webコントロール分のプロパティが作成されていて、画面に表示するためのvalueを作る役目。データを取得して、プロパティに値をセットしていくのだが、何でもかんでもModelに書きすぎることもあって、肥大化しやすい問題を抱えている（※1 という印象）。

※1 もしかしたら、クラス分けとオブジェクト化を進めていく中で整理可能なのかもしれない。ViewとControllerに比べて、どうにもコードが長いという印象がある。

■MVVM（Model,View,ViewModel）の場合

MVCと基本的には一緒だが、Viewのデータの出し入れに関しては、ViewModelが担っている。

ああ、わかる、と一番最初にMVVMを学んだときに思ったものだ。MVCのコントローラーなんてもっと上位の基盤でラップされていていいレベルじゃないの？Actionをコントロールしたいのはわかるんだけど、わざわざコードを書く必要があるのかね？って考えているのは私だけではないと思う。それこそ、専用のUIでも作ったら？っていうのが率直な感想だった。

■それでもやっぱりModelはでかくなる

ViewのデータアクセスをViewModelにお任せしたというものの、それでもやはりModelは肥大化していくケースが多いようだ。Modelそのものにコードを書きすぎることが主な原因になっているんだろう。まぁわかる。数か月後に自分が書いたコードを読んでいると、「手抜き」個所を発見することが結構な頻度である。ちょっと考えればわかることだったり、めんどくさがって新しいClassを作らなかったり。。私はWeb専門なので、MVVMに業務で触れる機会はないが、実際の現場は相当苦労していることだろう。ペアプロができれば、もうちょっと早い気づきができるのにという、本当に情けない「環境頼り」思考が頭をよぎる。

つくづく、情けない話だ。

まとめ

MVCにせよMVVMにせよ、そんなに難しい話ではない。.netのMVCは、プロジェクトのレベルで提供されている「機能」だから、考えなくてもそれなりに使いこなせるようになっている。MVVMもWPFで実現可能だ。プロジェクトという大きな枠組み（Framework）の中で、いずれかのアーキテクチャを採用しているはjavaも一緒だろう。

ただ、どのようなアーキテクチャを採用したにせよ、問題点、課題は尽きないだろうし、この先もトライ＆エラーが続いていく。ViewModelがあればModelが肥大化しないのではなくて、自身の思い込みだったり理解不足だったり手抜きだったりという、逃げの部分がModelを肥大化させているのだ、と深く反省した一日でした。

この反省を次に生かしたいと思う。