「MVVMは何となく避けて通っていた」
「なぜ」
「昔、MVCってのがあったんだよ」
「今でもあるよ」
「そこは突っ込むな。ともかくMVCは上手く機能しなかった」
「だから、名前が似ているMVVMを避けて通ったわけだね」
「まあ、そうだな」
「でも、違ったの?」
「そうだ。違った、Windows Phoneのコードを書いていて、ふと書いてきたソースを振り返った瞬間に驚いた」
「なぜ?」
「しっかりMVVMになっていたからだ」
「じゃあ、君がこうなるべきだと思って勝手に書いたコードがMVVMだったということ?」
「この場合はそういうことになる」
「それはなぜ?」
「WPFというか、Windows Phoneのアーキテクチャがそれを求めているので必然的にそうなった、という解釈もできるが、どうもそうでもない感じだ」
「というと?」
「昔々、MFCにはModelとViewがあったけどさ。基本的にViewはModelを知ってるけど、ModelはViewを知らない構造なんだ」
「そうか」
「でもさ。実際は両者が協調して動作しないととても性能が出せない」
「PCの性能が足りないってことだね」
「そうじゃない。PCの性能が上がっても焼け石に水だ」
「じゃあ、何?」
「MVVMのVとVMは双方向でインタラクトできるんだ」
「えっ?」
「WPFのバインディングで双方向のインタラクトが指定できるから、VM上でのデータ変更をVに反映することも、Vのレイヤーで起きたユーザー入力を自動的にVM上のデータに反映させることもできる」
「でもさ。2つを分けないで1つで書けばいいじゃん。面倒な連動なんて考えないでさ」
「そうじゃない。分けるメリットがあるんだ」
「えっ?」
「だからさ。VMレベルは抽象的な情報を提供するだけだが、Vレベルでは見せる実態を決める。だから、見かけをいじる場合は多くの場合Vだけでいい。必要な情報が提供されていない場合はVMもいじる必要があるけどね」
「それはいいことなの?」
「そうだ。外見の調整はよくある要求だが、それによって重要なロジックを壊してしまう可能性を減らせる」
「そうか」
「まあ、他にもいろいろあるけどな。まあ、自分のやっていたことが結果としてMVVMだと気づいた以上、これからはもっと意識的にMVVMしていくか」
「つまり、上から読んでもMVVM、下から読んでもMVVMってことだね」
