MVC&MVVM

ジャバ―ド先生！ちょっと大変なんだ！

ことりん君、こんにちは！今日はどうしたの？？

キリンさんのあれがこれで、あーなっちゃってこーなっちゃって…

いつもどおり大変そうなことは伝わってきたけど、ちょっと落ち着こうね。キリンさんってたしか前にRubyをおすすめしたよね？？

あ、そうそう！Webアプリケーションを開発したいって言ってたから、ジャバ―ド先生に教えてもらってRubyをおすすめしたんだ！その後、実際にRubyでWebアプリケーションを開発し始めたらしいんだけど…。

何か問題が起こったの？？

実はそうなんだ。キリンさん、まだまだ初心者なんだけどがんばってWebアプリケーションを開発したんだよね。んで、一応完成したんだ！でも、キリンさんがいうには、たとえば何かを1つを修正しようとすると、とっても手間がかかったり、ある機能を追加しようとしても、影響範囲が分かりづらくて、かなり苦労しているらしいんだ…。

なるほどなるほど。

キリンさんだけではなくて、他のエンジニアさんも同じような思いをしているのかなぁ？

そうだね。むしろ、現代だけではなくて先人たちも同じ道をたどってくる中で、同じようなことを考えて、そうならないためには、どうすればいいかっていう解決策を考えているんだよ。

あ、そうなんだ！やっぱりみんな同じなんだね！

そうそう。そういう困った状況に陥らないためには、プログラミングの前の基本設計・詳細設計という工程で、「メンテナンスや機能追加の容易さ」「パフォーマンスの拡張性」などを考えながら作業を進める必要があるんだよ。

あぁ、それはキリンさんやってないかもな…

そして、先人たちがたくさん考えた結果、「こうすればうまくいくよ」っていうパターンがあるんだ。

なるほど。エンジニアの先輩たちの血と汗と涙の結晶ってやつだね。例えばどんなやつがあるの？？

有名なのはMVC（エムブイシー）とかMVVM（エムブイブイエム）ってやつだね。

MVCとMVVM？

そう。アーキテクチャの原則として、UIロジック（画面表示に関わる処理）と、ビジネスロジック（画面に関わらない純粋な処理の部分）は分離してあげましょうっていうものがあるんだ。

ふーん。でも、なんで分離したいの？？

たとえば、「いまの画面がユーザーに分かりにくいから、思い切って画面を刷新しましょう」となったとき、UIロジックとビジネスロジックが複雑に入り組んでいると、修正がとても大変になるんだ。だから、UIロジックとビジネスロジックの関係を、できるだけ疎の状態にしておけば、影響範囲が限定されるっていうメリットがあるってわけなんだよ。

なるほど。じゃあそのUIロジックとビジネスロジックを分離するためのものがMVCとMVVMってことかな？？

そのとおり！MVCっていうのはそれぞれ以下の頭文字をとったものなんだ。

ModelとViewとControllerでMVCなんだね。あれ、じゃあMVVMっていうのは？Model – View – View – Modelってこと？？

惜しい！MVVMっていうのはこのとおりだよ。

むむむ！新しいのがでてきた！！ViewModelって何するの？？

そう。MVCっていうアーキテクチャだとControllerでやることが多くなりがちなんだ。Fat Controllerっていって、あまり良くない設計っていわれているんだ。それを解決したのがMVVMってやつなんだ。

MVVMだとそのFat Controller？ってやつが起きにくいのかな？

そうなんだ。MVVMだと、ViewとViewModelが自動的につながる感じなんだ。たとえばユーザーが入力した値は画面であるViewの値が変更されるんだけど、ViewModelではその変更を自動的に検知してViewModelの値も変更されるんだ。もちろん、その逆も然りでViewModelの変更はViewに自動反映されるイメージだね。

あぁ、そうか。MVCだとViewとModelはつながっていないから、Controllerで色々処理をやらないといけなくなっちゃうってことだね。だからControllerは太りやすいんだ。

そういうこと！でも、必ずしもMVCがダメってわけじゃないからプロジェクトの特性に応じて最適なアーキテクチャを選定することが大事なんだ。キリンさんもこのあたりを考えながら設計してみると上手くいくんじゃないかな？

なるほどねぇ。開発ってプログラミングするだけだと思ってたけど結構大変なんだね…。ちょっとキリンさんに教えてくるよ！ジャバ―ド先生ありがとう！

はーい！またいつでもどうぞ！