MVC&MVVM

この記事はMVC&MVVMについて解説した記事です。会話形式のやさしい文章で「MVC&MVVM」の用語のイメージを紹介した後に、採用に役立つMVC&MVVMの知識を解説しています。

1分で分かる!MVC、MVVMとは?

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

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

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

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

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

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

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

なるほどなるほど。

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

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

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

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

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

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

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

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

MVCとMVVM?

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

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

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

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

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

Model (データベースのアクセスなど、主にデータを扱う)
View (主に画面表示を行う)
Controller (ViewとModelを仲介する)

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

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

Model (データベースのアクセスなど、主にデータを扱う)
View (主に画面表示を行う)
ViewModel (ViewとModelを密接に紐づける)

むむむ!新しいのがでてきた!!ViewModelって何するの??

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

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

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

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

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

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

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

MVC&MVVMとは?採用に役立つ基礎知識

MVCとMVVMとは、ソフトウェアアーキテクチャの1種であり、UIロジックとビジネスロジックを分離するためのアーキテクチャパターンです。UIロジックとビジネスロジックが「密」の関係にあると、メンテナンス性や拡張性が著しく低下します。これを防ぐためのパターンがMVCやMVVMと呼ばれるものです。

MVC&MVVMを使うエンジニア

MVCやMVVMは、アプリケーションの開発における普遍的な考え方のようなものです。そのため、画面を伴うアプリケーション開発に携わるエンジニアは、誰もが把握しておくべき思想です。具体的にはフロントエンドエンジニアサーバーサイド(バックエンド)エンジニアネイティブアプリエンジニアなどは、知識としては必ず押さえておくべきものといえます。

MVC&MVVMを使うエンジニアの特徴と在籍業界

MVCやMVVMについては前述のとおりですので、特に特徴などはありません。また在籍業界についても、特に偏りはなく(UIを開発する可能性がある)全業界のエンジニアが知っておくべきものといえます。

採用する時に知っておくとよいこと

フレームワークとMVC&MVVM

それぞれのプログラミング言語にはフレームワークというものが存在します。たとえば、PythonであればDjangoRubyであればRuby on Railsといったものです。これらのフレームワークは、MVCやMVVMの設計思想を取り入れたものとなっています。

ただし、エンジニアとしてはMVCやMVVMがどういったものかは常識として知っておきたいところです。

求人のポイント

求人を作成する時は、下記の内容を求人に入れるとよいです。

1システム(サービス)の詳細
※特にそのシステム(サービス)をなぜ作っているのかを熱量をもって記載する。
2開発環境
3現在のエンジニア組織の体制
4現行システムの課題と募集の背景
5求められる業務と期待値
6エンジニアとしてのスキルアップ支援制度の有無と詳細
7エンジニアチーム内での相互成長のための仕組み(勉強会やLT会など)の有無と詳細
8選考フロー
9待遇
10キャリアパス

MVC&MVVMの豆知識

## MVCとMVVMとMVP

これまでMVCとMVVMについて説明してきました。実は同じUI関連のアーキテクチャとしてMVPと呼ばれるものもあります。MVPとは、MVCやMVVMとおなじようにModel–View–Presenterの頭文字からなるものです。詳細は割愛しますが、UI関連のソフトウェアアーキテクチャの1つとして認識しておきましょう。

関連記事

  1. ShellScript

  2. R言語

  3. CSS

  4. Node.js

  5. メタバース

  6. Gem