章: 第4章: Laravelフレームワーク
コントローラが肥大化して、1ファイルに何百行もある状況になっていませんか?
バリデーション・DB操作・メール送信……すべてをコントローラに詰め込むと、テストも修正も困難になります。コントローラはリクエストを受け取り、適切なレスポンスを返す「司令塔」に徹するのが正しい設計です。
コントローラが肥大化すると何が起きるか
1つのメソッドが50行を超えるようになると、単体テストが書きにくくなり、同じロジックが別のアクションにコピーされ始めます。アクションを1責務に絞ることで、保守性とテスト容易性が大きく向上します。
コントローラ設計の良い例・悪い例
| 観点 | 悪い例 | 良い例 |
| 責務 | バリデーション・DB・メールを全部書く | 各責務をサービス・リクエストクラスに委譲 |
| アクション数 | 1コントローラに10以上のメソッド | 7つのRESTアクション内に収める |
| 戻り値の型 | 型宣言なし | : View : RedirectResponse を明示 |
| 命名 | doSomething など曖昧な名前 |
index / store / show / destroy などRESTに従う |
チェックポイント: アクション内でビジネスロジックを書き始めたら「このロジックはどこに属するか」を問い直しましょう。DBアクセスはEloquent/Repository、バリデーションはFormRequestクラスに移動するのが目安です。
コードサンプル
<?php
// php artisan make:controller PostController --resource
class PostController extends Controller {
public function index(): View {
return view('posts.index', ['posts' => Post::latest()->get()]);
}
public function store(StorePostRequest $request): RedirectResponse {
Post::create($request->validated());
return redirect()->route('posts.index');
}
public function destroy(Post $post): RedirectResponse {
$post->delete();
return redirect()->route('posts.index');
}
}
まとめ & 次のステップ
- コントローラは「受け取る・判断する・返す」の3役に徹し、ロジックを持たせないのが理想です
--resourceフラグで7つのRESTアクションを持つスケルトンを自動生成できます- 戻り値の型を明示することで、返却ミスをIDEや静的解析が早期に検出できます
- バリデーションはFormRequest、ビジネスロジックはServiceクラスに切り出しましょう
- アクションが複雑になってきたら単一責務を意識してクラスを分割するサインです
次回は Bladeテンプレート を学びます。HTMLに動的な処理を混ぜるLaravel標準のView実装を整理しましょう。