Laravelに入門すると「Migration?Model?Controller?Route?View?」と、知らない単語が一気に出てきます。
実はこれらは全部「役割分担」で動いているだけです。口コミアプリ(ReviewSystem)を例に整理してみましょう。
🎯 全体像:Laravelは“役割分担”でわかりやすくなる
Laravelは大きく4つの要素で考えると理解しやすいです。
- Migration(マイグレーション) …「データベースの設計図」
- Model(モデル) …「データの窓口(DBと話す担当)」
- Controller(コントローラ) …「司令塔(処理の流れを決める)」
- View(ビュー/index.blade.php) …「見た目(HTMLを出す画面)」
そして、それらを Route(ルート) がつないで「どのURLでどのコントローラを呼ぶ?」を決めます。
1. Migration(マイグレーション)が必要な理由
何者?
- データベースの設計図をコードで書いたもの。
- 「
reviewsテーブルにitem_name(対象名)、title(タイトル)、body(本文)、rating(星評価)を作ろう」と宣言します。
なぜ必要?
- phpMyAdminで手作業せずにテーブルを作れる
- チームで同じ設計を共有できる
- 過去の変更を履歴管理できる
どう使われる?
-
php artisan migrateを実行すると、設計図どおりにテーブルが作られる。 - 作り直したいときは
php artisan migrate:fresh。
たとえ:家具を置く前に「間取り図」を決めるイメージ。間取り図=Migration、家(DB)に部屋(テーブル)を作るのが
migrate。
2. Route(ルート)が必要な理由
何者?
- URLと処理を結びつける地図。
-
routes/web.phpに「/reviewsに来たらReviewController@indexを実行」と書く。
なぜ必要?
- ブラウザは「URL」しか送ってこない。
- そのURLからどの処理を呼ぶかLaravelに伝える役割。
どう使われる?
Route::get('/reviews', [ReviewController::class, 'index'])->name('reviews.index');
→ /reviews にアクセスすると ReviewController@index が実行される。
たとえ:駅の案内板。「A出口 → コントローラAのindex行き」と指示している。
3. Controller(コントローラ)が必要な理由
何者?
- 司令塔。やるべき処理を決める。
- 例:「DBから口コミを取り出してビューに渡す」。
なぜ必要?
- 処理を見た目(View)から分離することで、わかりやすく保守しやすい。
どう使われる?
public function index()
{
$reviews = Review::latest()->get(); // モデル経由でDB取得
return view('reviews.index', compact('reviews')); // ビューに渡す
}
たとえ:レストランの注文管理係。キッチン(DB)に注文して、料理(データ)をホール(View)に渡す。
4. Model(モデル/Eloquent)が必要な理由
何者?
- データベースとやり取りする窓口。
- 例:
Reviewモデルはreviewsテーブルとつながる。
なぜ必要?
- SQLを書かずに PHPのコード感覚でCRUD ができる。
-
Review::create([...]),Review::latest()->get(),$review->update([...])など。
どう使われる?
- コントローラが「口コミを取ってきて」と言ったら、モデルがDBから持ってくる。
たとえ:外国語の通訳。SQLを直接話さなくても、Eloquentを通じてやり取りできる。
5. View(ビュー/index.blade.php)が必要な理由
何者?
- ユーザーに見せるHTMLのファイル。
-
resources/views/reviews/index.blade.phpが「投稿フォーム+一覧画面」。
なぜ必要?
- 見た目と処理を分けるため。
- Bladeの記法(
@if,@foreach,{{ }})で、コードとHTMLをシンプルに書ける。
どう使われる?
- コントローラから
view('reviews.index', ['reviews'=>$reviews])と呼ばれ、
{{ $review->title }}などでデータを埋め込んで画面に表示される。
たとえ:料理をお皿に盛り付ける。データ=料理、盛り付け=View。
🔗 データベースと画面表示はどうつながる?
例:/reviews にアクセスして一覧を表示する流れ
-
ブラウザが
/reviewsにアクセス -
Route:「このURLは
ReviewController@index」 - Controller:「DBから口コミ一覧を取ってViewへ渡そう」
-
Model:「
reviewsテーブルにSQLを投げて結果を返す」 -
View:「受け取った
$reviewsを@foreachでHTMLに並べる」 - ブラウザに一覧が表示される 🎉
🖊 投稿・更新・削除の流れも同じ
- 投稿:フォーム(POST) → Route → Controller(store) → Model(保存) → View(完了メッセージ)
- 更新:フォーム(PUT) → Route → Controller(update) → Model(更新)
- 削除:フォーム(DELETE) → Route → Controller(destroy) → Model(削除)
✨ 一言まとめ
- Migration:DBの設計図
- Model:DBと会話する窓口
- Route:URLの案内板
- Controller:処理の司令塔
- View:見た目の画面
この流れを意識すると「どこに書けばいいの?」が分かり、Laravelがぐっと使いやすくなります。