コントローラの責務と、薄く保つ考え方

コントローラの役割

コントローラは、ルーティングが決めた行き先です。役割はシンプルで、「リクエストを受け取り」「必要な処理を適切な担当に振り分け」「結果を画面やJSONとして返す」という交通整理です。自分自身が計算や複雑な判断を全部抱え込む場所ではありません。

リソースコントローラ

Day3のレッスン1で見たリソースルートに対応するのが「リソースコントローラ」です。index・create・store・show・edit・update・destroy という定番メソッドを持つコントローラを、コマンド1つで雛形生成できます。命名が揃うので、どのメソッドが何をするか誰でも予測できます。

// $ php artisan make:controller PostController --resource

class PostController extends Controller
{
    public function index() { /* 一覧を返す */ }
    public function create() { /* 作成フォームを返す */ }
    public function store(Request $request) { /* 保存する */ }
    public function show(Post $post) { /* 詳細を返す */ }
    public function edit(Post $post) { /* 編集フォームを返す */ }
    public function update(Request $request, Post $post) { /* 更新する */ }
    public function destroy(Post $post) { /* 削除する */ }
}

薄いコントローラ vs 太ったコントローラ

同じ「投稿を保存する」処理でも、書き方で保守性が大きく変わります。業務ロジックをコントローラに直書きしたものと、処理を別の担当(サービス層など)に委ねたものを比べてみましょう。

public function store(Request $request)
{
    // バリデーションも、業務ルールも、DB保存も、通知も全部ここに…
    $data = $request->all();
    if (mb_strlen($data['title']) > 100) { /* 独自チェック */ }
    $slug = mb_strtolower(str_replace(' ', '-', $data['title']));
    $post = new Post();
    $post->title = $data['title'];
    $post->slug = $slug;
    $post->save();
    // メール送信やSlack通知までここに直書き…
    Mail::to($post->user)->send(new PostCreated($post));
    return redirect('/posts');
}

public function store(StorePostRequest $request, PostService $service)
{
    // 入力チェックはフォームリクエストへ、業務ロジックはサービス層へ委譲
    $post = $service->create($request->validated());

    return redirect()->route('posts.show', $post);
}

コントローラを薄く保つ指針

• 1メソッドは「受け取る・委ねる・返す」の3ステップに収まるのが理想。
• 入力の検証は、コントローラではなくフォームリクエストに寄せる。
• 業務ルール(いつ・どんな計算をするか)は、サービス層やモデルに置く。
• 同じ処理を複数のコントローラから呼びたくなったら、それは切り出すサイン。
• テストしづらいと感じたら、責務が混ざっている可能性を疑う。