バリデーションの置き場所として基本になるのはどれですか。
コントローラが検証で膨らむのを防げ、authorize() で認可も同じクラスに書けるからです。ただし一意性のような整合性は、DB側にも制約を張らないと同時実行ですり抜けます。
面接官が見ているのは置き場所を意識しているか。
よくある答えと、面談でどう見られるか
- FormRequest に切り出す。整合性が要る項目は DB 側にも制約を張る
その通りです。アプリ側のチェックだけだと、一意性などは同時実行ですり抜けます。 - コントローラの中に $request->validate() を書く
小規模なら許容されますが、同じ入力を扱う箇所が増えるとルールが散らばります。 - モデルの保存直前にまとめて検証する
動きはしますが、入力検証はリクエスト層の責務です。エラーメッセージを画面に返す部分が面倒になります。 - フロントエンドの JavaScript だけで検証する
JS は無効化できますし API を直接叩かれます。サーバー側の検証は必須です。
面接官は何を見ているか
- FormRequest / コントローラ / 手動 Validator のどれかを挙げ理由を言えた
- 責務の分離という観点に触れた
- DB制約との使い分けを意識していた
模範解答
基本は FormRequest に切り出します。コントローラが検証で膨らむのを防げますし、authorize() で認可も一緒に書けるからです。ただしバリデーションはあくまで入力の検査なので、一意性のような整合性はDB側にも制約を張ります。アプリ側のチェックだけだと、同時実行ですり抜けます。
ここからどう深掘りされるか
この問いに答えられた場合、面談は次の質問に進みます。
観点をすべて押さえられた場合
FormRequest に寄せると困る場面はありますか。一部しか触れられなかった場合
コントローラに直接バリデーションを書くと、何が困りますか。