Laravelを昨年の10月ほどから触り始めましたがFormRequestが便利だなーと思いました。
便利だと感じたのは以下の3点です。
MVCというパターンを知って最初にやりがちなこととして、ロジック/DB操作などがControllerに記述されControllerが肥大化することでしょう(FatController)。
FatControllerの何が悪いというとロジックの見通しが悪くなることでしょう。
個人開発なら個人の事なのでお好きにどうぞとは思いますが、チーム開発の場合は他の人がコードを触ることがあります。
修正や機能追加の際には該当箇所の当たりをつけやすくしておくことは必要でしょう。
ロジック/DB操作に関しては、以下のように切り分けてコードを分離していくところが多いと思います。(SI系は特に??)
Controllerの役割はリクエストの振り分けがメインなので、バリデーションに関しても可能な限りControllerに書かないほうが良いです。
LaravelのFormRequstのバリデーション機能は色々そろっており、ControllerやServiceにバリデーションのロジックが入り込まなくてよくなるでしょう。
FormRequestを使わずに値を受け取るときに想定と違った値が入っているというのを避けることができます。
Requestで受け取る値が単項目とかであればFormRequestにするかどうかは微妙な部分ではありますが…。
あと便利な点として以下のメソッドをOverrideすれば、クエリパラメータのバリデーションも実施できます。
// FormRequestをextendsしていることが前提 public function rules() { return [ 'param' => 'required|string|max:4' ] } public function validationData() { $param = $this->query('param'); return array_merge($this->all(), compact('param')); }
上記の例だとURL?param=○○の「○○」は必須で4文字までの文字列が入ることが保証される。
最近のPHPは引数の型指定ができるようになってきています。
なのでController → Service(メインロジック)へ値を渡すときに型を制限することで何の値が渡されているか明確にできます。
単純にFormRequestを継承したクラスを渡すだけでも、rulesの中身を見ることでパラメータ名は分かるので$this->input(”)で指定すれば取れます。
何か変換する必要があれば$this->input(”)を直接指定せずgetterを実装して変換後の値を渡したりとかもできます。
Requestクラスのall()でServiceへ値を渡すよりは情報量があるのでわざわざ「ここってどんな名前でパラメータが飛んでくるんだっけ」というのを調べる手間が省けます。
次回あたりFormRequestを使ってControllerの見通しをよくする実例をお伝えできればと思います。
(ついでにServiceやRepositoryあたりも交えて)