Fat Controller
行数が多く密結合なController
「(知見なく)普通に書いてたら普通にFatになる」のであれば、そもそも「Controller」という概念の切り方が悪いと思うmrsekut.icon
そんなことを言っても仕方ないがmrsekut.icon
MVCという枠組み自体が正しい使い方を簡単に、誤った使い方を困難にに反している
とは言えツールの思想に則るも重要であるので、「MVCに則るフレームワーク」を使っている場合にはControllerを書かないといけないので、その時に気をつけることについて
よくあるtips
リクエストのデータを処理する関数は FormRequest に書く ref
FormRequestを何かしらんmrsekut.icon
Laravel特有の概念?
そうだとして何?
Class?もっと小さい概念?
いつ使うもの?
何が便利?
Symfonyで実装はできる?
レスポンスのデータを処理する関数は ViewModel あるいは Resource に書く ref
Resourceってなに?
Laravel固有の話なのかDDDの話なのか判別できないmrsekut.icon
記事としては良さそうなんだけど知識不足で理解できない。悲しいmrsekut.icon
シングルアクションコントローラーにする ref
Laravel固有の話なのかDDDの話なのか判別できないmrsekut.icon
複数の Controller に分離する
Usecase Interactorを使う
https://qiita.com/nunulk/items/6ed409345efb6ee4f660#5-usecaseinteractor-を使う
Entityに書くべき処理はEntityに
https://qiita.com/nunulk/items/e9f4c221e60de6d016a5
Validationを切り出す
/kawasima/Fat Controller改善ガイド#5e6a3d4ea8e5b200007638cd
自分で書くのではなくフレームワークのソレに則る
ファサードを導入する
/kawasima/Fat Controller改善ガイド#5f646c78a8e5b2000049bc01
決まった一連の処理はFacadeパターンにする
同じ一連の呼び出しをしている箇所は、すべてファサードを経由するようにしておくことが重要
マジックナンバーの取り扱い
/kawasima/Fat Controller改善ガイド#5e6a3d4ea8e5b200007638e1
アスペクト指向プログラミングをやる
/kawasima/Fat Controller改善ガイド#5e6a3d4ea8e5b20000763901
ドメインモデル貧血症
#??
fat controllerに書いてあるような処理を分割してどこに定義すべきなのか
Service Class?
Controller内の別のmethod?
例えばめちゃくちゃでかいControllerを、そのController Classの中で
細かく細かくmethodに分けていき
分けきった後に、他の層(EntityやRepositoryなど)に配分をしていく、という方法はあり?
/kawasima/Fat Controller改善ガイド
https://medium.com/veltra-engineering/intent-response-pattern-c1be6aa9f2e5