Day 1・MVCとリクエストライフサイクル、Laravelを選ぶ理由
リクエストがレスポンスになるまで
ブラウザのリクエストが、ルーティング→ミドルウェア→コントローラ→ビューを通ってレスポンスになる流れを理解する。
1本の道として理解する
(リクエストライフサイクル)とは、ブラウザからのリクエストが、どんな順番で処理されて最終的にレスポンス(HTMLなど)になるかという「1本の道」のことです。この流れを理解しておくと、不具合が起きたときに「どの段階で問題が起きたか」を切り分けられるようになります。
- ブラウザがURLにリクエストを送る(例: GET /users/1)
- ルーティングが「そのURLはどの処理か」を判定する
- ミドルウェアが前処理を行う(ログイン確認など)
- コントローラが処理の中身を実行する(Modelでデータ取得)
- ビューがデータをHTMLに組み立てる
- ミドルウェアが後処理を行い、レスポンスがブラウザに返る
ルーティング: URLと処理の対応表
ルーティングは「このURLに来たら、この処理を呼ぶ」という対応表です。Laravelでは routes フォルダにルートを定義します。ここで初めて、URLとControllerのメソッドが結び付きます。
<?php
// routes/web.php — URLと処理の対応表
use App\Http\Controllers\UserController;
use Illuminate\Support\Facades\Route;
// GET /users/1 が来たら UserController の show を呼ぶ
Route::get("/users/{id}", [UserController::class, "show"]);ミドルウェア: 処理の前後に挟む関所
(ミドルウェア)は、コントローラにたどり着く前後に挟む「関所」です。たとえば「ログインしていない人は追い返す」「全リクエストをログに残す」といった共通の前処理・後処理をここで行います。各Controllerに同じチェックを書かずに済むのが利点です。
<?php
// ログイン必須の関所を通してから処理する例
Route::get("/mypage", [MyPageController::class, "index"])
->middleware("auth"); // 未ログインならログイン画面へリダイレクトなぜミドルウェアで共通処理を挟むのか
ログイン確認のような共通チェックを各Controllerに毎回書くと、書き忘れが必ず発生します。書き忘れれば、その画面だけ認証が抜けるという重大なセキュリティ事故につながります。ミドルウェアとしてルートにまとめて適用すれば、チェックが一箇所に集約され、抜け漏れを防げます。「横断的な関心事は一箇所にまとめる」という考え方です。
補足: 「道の途中」で何が起きるか
リクエストは行きにミドルウェアを通ってControllerに入り、帰りにもう一度ミドルウェアを通ってブラウザに戻ります。行きで認証、帰りでレスポンスヘッダー追加、といった前後の処理を1つのミドルウェアに書けるのはこのためです。
面接ではこう言う
「リクエストはルーティングでURLと処理が対応づけられ、ミドルウェアで認証などの共通前処理を通り、コントローラが処理を実行し、ビューがHTMLを組み立てて返る、という流れで処理されます。この流れを把握しているので、不具合が起きたときにどの段階が原因かを切り分けられます」と、トラブルシュートに結びつけて話すと実務力が伝わります。
読んでも腑に落ちない所は、AIに噛み砕いてもらいましょう。
理解度チェック
答えられれば、面接で説明できる状態に一歩近づきます。
「ログインしていないユーザーを、コントローラに到達する前に追い返したい」。この処理を書く最も適切な場所はどこか。
リクエストがレスポンスになるまでの流れを、ルーティング・ミドルウェア・コントローラ・ビューという語を使って説明してください。
記述式です。まず自分の言葉で答えを考えてから、模範解答を開いて自己採点してください。