LaravelのFormRequestはバリデーション処理をまとめる便利な仕組みとして使われるが、その責務範囲については設計次第で解釈が分かれやすい領域でもある。特にリダイレクトやHTTP依存の処理まで含めるべきかどうかは、アプリケーション設計上の重要な論点となる。本記事ではFormRequestの役割と責務分離の考え方を整理する。
FormRequestの基本的な役割
FormRequestはLaravelにおいて、HTTPリクエストに対するバリデーションと認可処理を担当するクラスである。
例えばコントローラ内に書かれていたバリデーションルールをFormRequestへ移すことで、責務を分離しコードの可読性を向上させることができる。
バリデーション以外の責務はどこまで許容されるか
FormRequestは単なるバリデーション専用クラスではなく、authorizeメソッドやfailedValidationなどを通じてHTTPライフサイクルに一部関与する。
例えば入力チェック後のエラーレスポンスの形式変更などは許容されるが、ビジネスロジックまで持たせるのは推奨されない。
リダイレクト処理をFormRequestに含める設計の是非
FormRequestでリダイレクト先を制御することは技術的には可能であるが、責務の観点では議論が分かれる。
例えばfailedValidationをオーバーライドして特定ルートへリダイレクトすることはできるが、複雑化するとControllerの責務が不明瞭になる。
Controllerとの責務分離の考え方
一般的にはControllerはユースケースの制御、FormRequestは入力検証と認可という役割分担が推奨される。
例えば正常時の遷移や業務ロジックはControllerまたはService層に任せ、FormRequestは入力の妥当性に集中させる設計が保守性を高める。
HTTP依存ロジックの配置に関する設計指針
HTTPに依存する処理をどこに置くかは設計思想によって変わるが、過剰にFormRequestへ集約するのは避けるべきである。
例えばリダイレクトやレスポンス制御をControllerに寄せることで、FormRequestの再利用性とテスト容易性が維持される。
まとめ：FormRequestは「検証責務」に留めるのが基本
FormRequestはLaravelの中でも強力な仕組みだが、責務を広げすぎると設計が複雑化する。
バリデーションと認可に集中させ、リダイレクトやビジネスロジックはControllerやService層に分離することで、長期的に保守しやすい設計となる。
コメント