アプリケーションの開発をしているといずれMVCモデルという言葉に出会うかと思います。
私自身ざっくりとしか理解していない部分も多いので、ここで改めてまとめてみることにいたします。
MVCモデルとは？
まずMVCは3つの要素からなり、それぞれ以下になります。
- M＝Model（モデル）
- V＝View（ビュー）
- C＝Controller（コントローラー）
なぜMVCモデルが必要なのか？
MVCの構成要素は把握したとして、それぞれを見ていく前に、そもそもなぜMVCモデルが必要なのかを理解しておくことが重要です。
わかりやすく大きく分けると一つ目はプログラムはプログラマー、ビューによるデザイン部分はデザイナーがそれぞれのファイルを単独で修正できるようにという部分が大きいと思います。
二つ目は似たような処理で似たようなコードを多数の場所に書いてしまうことを避けること、汎用性の高さやコードの再利用がしやすいことが挙げられます。
という目的の元に使わなければ、結局のところモデルに書くべき処理をビューに書いてしまったりなんてことは使う人次第なので注意が必要な部分でもあります。
Model（モデル）
ビジネスロジックを書くとされている部分、いわゆるプログラムのコード部分と最初は思っておいて良いでしょう。
Viewと分離したプログラム部分として話を進めます。
View（ビュー）
webアプリで言えばHTMLやCSSによるデザイン部分、ここはデザイナーが修正できる、あるいはデザイナーが上げたHTMLをそのまま利用できるくらいまで分離できると作業分担がスムーズです。
表示に関わる部分で、プログラムとは分離した部分としていきましょう。
Controller（コントローラー）
ここがちょっとややこしいと思います。役割としてはモデルとビューの中間を担う役割とされています。
例としてはモデルでDBから取得した値を、ビューに引き渡すといった処理を行う部分という感じかなと思います。
MVCモデルは必要なのか？
大体のフレームワークでMVCモデルが採用されているので使わざるを得ない状況かと思いますが、中には使わないという方もいます。
別にMVCモデルが強制ではなく、上記のように作業の分担やコードの再利用、保守性の高いコードを書くことが目的です。
フレームワークを使おうがそのすべてがダメダメなコードは書けますので、結局は使い人次第になる部分も確かにあります。
ただ最初の入り口としては既に確立されたアーキテクチャを利用して勉強する方がいいと思いますので、とりあえずやってみたらいいと思います。
保守性を意識する
最初のうちは特にそうかと思いますが、とにかく動けばいいという状態のものを作ってしまいがちです。まだ経験も浅ければ悪いことではなく当然のことです。
ただし動けばいいというレベルで書かれているコードが問題になるのは、そのコードの修正・機能拡張などを行う時になります。
読みづらく、理解しづらい構成になっていればどこをどう修正すればいいかの検討にも時間がかかり、何かを修正すれば他に不具合がでるなどのデグレを引き起こす可能性もあります。
最初は仕方ありませんが、徐々にこのコードは後から管理しやすいか、保守性の高いコードになっているかの見直しをすると良いかもしれません。
フレームワークの利点
そこでフレームワークの利点の部分ですが、ある程度構成が決まっているので誰が書いても比較的同じような使い方になるというメリットがあります。
誰が書いても同じなんて書くと悪いことのように思いますが、後から誰か別の人が見てもなんとなくはわかるというのはメリットでもあります。
他人の書いたコードを追うのは大変ですからね…例えフレームワークを使っていたとしたって大変なことが多いです。
就職を目指すなら保守性の高さをアピールしたい
もし今からエンジニア職を目指すのであれば、gitでコードを見られるか、あるいは課題の開発を行うか実際にコードを書くような試験も多いと思います。
そこで保守性の高い綺麗なコードを書いているとかなりポイントが高いので、就職試験を目指している方は保守性の高さをアピールできるように意識しておくと良いです。
webであればプラスでセキュリティに脆弱性が無いかもしっかり確認しておくと良いですね。
まとめ
以上、今回はMVCモデルというアーキテクチャについて見ていきましたが、ハッキリ言ってこのあたりの絶対的な正解はありません。
もうMVCモデルは古いという意見もあるでしょうし、今後別の物が主流になる可能性も大いにあります。
引き続き、新しい情報は収集しておくと役にたつことがあるかもしれませんね。