分かりやすさ優先で書いてるから表現が正しくない箇所めちゃあるで、ゴメンやで🙏

MVCフレームワークの簡単な説明

「どの役割はどこに書く」ってルールが決まってるタイプのソフトウェアのことだよ。

ソースコードを書くときに「一定のルールを作って皆んなでそれを守りながら書いたらめっちゃ開発ラクじゃん！？？」って感じ。

地のソースコードのとき

MVCみたいなフレームワークが登場する前のお話。

一般的なWebサイトってサイトにアクセスすると、そのサイトの表示に必要なデータをDBから引っ張ってきて、それをいい感じにHTMLの中に組み込んでそれを最後に表示する流れが大半。

これを（例えばPHPで）ベタ書きすると以下みたいになる。

DBとのやりとり
それの描画

の処理が同じファイルに書かれている。

index.php

<?php
// ここでDBとやり取りする
$query = "SELECT * FROM users WHERE email = :email LIMIT 1";
$stmt = $dbh->prepare($query);
// 以下にまだDBとのやりとりが続く
$user = $stmt->fetch(PDO::FETCH_ASSOC);
?>
<head>
<!-- ここに諸々の設定 --->
</head>
<body>
    <h1><?= $user['name']; ?>さん、こんにちは。</h1>
    <div>
        <p><?= $user['name']; ?>さんの記事一覧は<a href="https://~~~.com/articles.php">こちら</a>から。</p>
    </div>
</body>

どこに何がかいてあるんやっけ？

コードの量やファイルの数が少ないうちはあまり気にならない（処理が目視で追える程度の量）。

でも段々とコード量やファイル数が増えてくるにつれて、どこにどんな処理が書いてあるのか「ルールがないから」めちゃ分かりづらくなる。

しかも「書き方のルールがない」からほかのエンジニアと一緒に作業したときに、人によってコードの書き方がバラバラになる可能性がある。

A氏「ページの表示に必要な処理は1枚のファイルに書いた方がスッキリするでやんすから、ワイはPHPの処理はファイルの上側に、HTMLはファイルの下側に寄せて書く派でやんす🤓」

B氏「結局最後はHTMLに変換されるでやんすから、ワイは先にHTMLをガシガシ書いていって、必要になったら要所要所でPHPを書く派でやんす🤓」

C氏「異なる言語が1枚のファイルに混在するのは嫌いでやんすから、ワイはHTMLとPHPはファイルごと分けてrequireで読み込む派でやんす🤓」

この3人が同じWebアプリを担当するってなったら、手戻りの連発や異なる文化による軋轢が生まれるのは必至でやんす（あ、もう「やんす」じゃなくていいか）。

MVCが登場したら管理がラクになったよ！

そこでこれらの問題を解決するために生まれたのが「MVC型フレームワーク」ってこと。

ちょっとだけMVCの解説

Model、View、Controllerの頭文字を取って「MVC」と呼ばれてるよ💡。

Modelはデータを操作できる
- データベースとやり取りしてくれる。DB屋さんと思ってもらってOK。
Viewでサイトの描画できる
- HTMLとやりとりしてくれる。HTML屋さんと思ってもらってOK。
Controllerは両者を仲介する
- ModelとViewとの間に入って仲介してくれる。仲介業者と思ってもらってOK。

これらの処理を書く場所を決めようZE☆

今までは皆んなが思い思いの場所ややり方で書いてたのを「ちょ、一旦共通のルールで書きませんか？🤴」って導入された。

DBとのやり取りが含まれる処理はModelが担当して、Model内に全部書く。

最後の描画系のコードはViewが担当して、View内に全部書く。

どのページにアクセスされたときに「どのModelを呼び出して、どのViewを返すか」みたいな仲介の役割はControllerに全部書く。

こうすることで同じWebアプリを複数人が開発するってなっても、皆んなが共通のルールで気持ちよく開発できるね！😌

余談

🤓の気持ちに入りすぎて、🤓のセリフ終わってるのに間違えて語尾に「やんす」って続けちゃった😂

俺「MVC型のフレームワークってなんやねん」