MVCアーキテクチャ
MVCとは
MVC は、アプリケーションを Model・View・Controller の3つの役割に分ける設計の考え方です。1970年代に生まれた古い発想ですが、いまも多くの [[フレームワーク]] の土台になっています。
目的は「変更の影響範囲を閉じ込めること」です。画面のデザインを直したいだけなのにデータベース処理まで壊れる、といった事故を防ぎます。
3つの役割
| 役割 | 担当すること | 例 |
|---|---|---|
| Model | データとビジネスルール | ユーザー情報の取得・保存、料金計算 |
| View | 表示の見た目 | HTMLテンプレート、JSONの整形 |
| Controller | 受付と交通整理 | リクエストを解釈し、Modelを呼び、Viewを選ぶ |
覚え方としては、Model が「何を」、View が「どう見せるか」、Controller が「どの順で処理するか」を担当します。
リクエストが流れる順番
- ブラウザが
/users/1にリクエストを送る - ルーティングが対応する Controller を呼ぶ
- Controller が Model に依頼し、Model が [[ORM]] などを通じてデータベースから取得する
- Controller が結果を View に渡し、View が HTML(または JSON)を組み立てて返す
// Controller は薄く保ち、データ取得や計算は Model に任せる(Express の例)
app.get('/users/:id', async (req, res) => {
const user = await User.findById(req.params.id); // Model に任せる
res.render('users/show', { user }); // View に渡す
});
よくある失敗と派生形
- ファットコントローラ: Controller に業務ロジックを書きすぎて肥大化する。最も多い失敗
- ファットモデル: Model が何百行にもなる。サービス層を足して分割することが多い
- MVVM / MVP: 画面側の状態管理を担う層を分けた派生形。フロントエンドのフレームワークでよく使われる
[[SPAとMPA]] のうち SPA が主流になった現在は、サーバー側が View の代わりに [[REST API]] として JSON を返し、画面の組み立てはブラウザ側が担当する構成も一般的です。この場合も Model と Controller の分離は有効なままです。
初学者向けポイント
- MVC は法律ではなく指針です。フレームワークごとに解釈が違うので、まず採用フレームワークの流儀に従う
- 迷ったら「この処理は画面が変わっても必要か?」と自問する。必要なら Model 側です。役割分担の発想は [[デザインパターン]] と同じく、テストのしやすさに直結します
関連技術とのつながり
- [[フレームワーク]] — 多くのWebフレームワークがMVCを前提に構成されている
- [[デザインパターン]] — 責務を分けて変更に強くするという共通の考え方
- [[ORM]] — Model がデータベースとやり取りする際の代表的な道具
- [[REST API]] — View の代わりに JSON を返す構成でも Controller の役割は同じ
- [[SPAとMPA]] — 画面をサーバーとブラウザのどちらで組み立てるかで構成が変わる
Q: MVC における Model の役割はどれ?
- [x] データの取得・保存や業務ルールを担当する
- [ ] HTMLの見た目を組み立てる
- [ ] リクエストを受け取って処理の順番を決める
解説: Model がデータと業務ルール、View が見た目、Controller が受付と交通整理を担当します。
Q: MVCで最もよくある失敗として挙げられているのはどれ?
- [ ] Viewにデータベース接続を書くこと
- [x] Controllerに業務ロジックを書きすぎて肥大化させること
- [ ] Modelを複数のファイルに分割すること
解説: ファットコントローラと呼ばれる典型的な失敗です。ロジックはModel側に置くのが基本です。
Q: MVCを採用する主な目的はどれ?
- [ ] プログラムの実行速度を上げるため
- [ ] ファイル数を減らすため
- [x] 役割を分けて、変更の影響範囲を閉じ込めるため
解説: 表示を変えたらデータ処理まで壊れる、といった事故を防ぐための責務分離が目的です。