エンジニア1年目奮闘日記「#2　ファットコントローラー解消！」

2024年10月2日

はじめに

こんにちは！お久しぶりです！半年前にエンジニアデビューをしたKです！

エンジニアスキルはまだまだですが、業務を通して日々学習を続けています！

先日、先輩にコードレビューしていただいた時に、「ここ！ファットコントローラーになってるよ！」とご指摘いただきました。

しかし、その時は「ファットコントローラー」とは何か全く理解していませんでした。

そこで今回は、ファットコントローラーとは何か、その解決策について、備忘録として書いていきたいと思います。

ファットコントローラーとは、MVC（Model-View-Controller）アーキテクチャにおいて、コントローラーに過度に多くのロジックが集中してしまった状態を指します。これが起こると、コードの可読性が低下し、保守が困難になり、またテストも難しくなります。

MVCモデルは、アプリケーションを以下の3つの部分に分けるアーキテクチャパターンです。

①Model(モデル)：データやビジネスロジックを管理

②View(ビュー)：ユーザーインターフェースを担当

③Controller(コントローラー)：ユーザーの入力を処理し、モデルとビューを仲介

①メンテナンス性の低下

ロジックがコントローラーに集中することで、コードの変更や修正が困難になります。

②再利用性の低下

特定のロジックがコントローラーに埋め込まれることで、他の部分で再利用が難しくなります。

③テストの困難さ

コントローラにロジックが集中すると、ユニットテストが難しくなります。

コントローラーの役割は、主にユーザーの入力を受け取り、それを処理することです。

具体的には以下のような役割を持ちます。

①ユーザーが入力したデータの確認と適切な形式への変換

②必要なモデルの呼び出し

③ビューへのデータの送信

コントローラーは、アプリケーションのロジックを持つべきではなく、単にリクエストを受け取り、適切なサービスやモデルに異常する役割を果たすべきです。

ファットコントローラーを避けるためには、いくつかのアプローチが考えられますが、ここでは最初に見直すべき3つの解決策を記述します。

①バリデーションの移行

バリデーションはコントローラーではなく、専用のクラスに移行します。

これにより、コントローラーはバリデーションのロジックから解放され、シンプルになります。

②データベースロジックの分離

データベースに関するロジックは、モデルまたはリポジトリクラスに移行します。

これにより、コントローラーはデータ処理の詳細から解放され、主な役割に集中できます。

③サービス層の導入

ビジネスロジックをサービス層に移行し、コントローラーの責任を軽減します。

サービス層は、複数のモデルにまたがる操作や、複雑な計算を含むロジックなどを集中管理する場所として機能します。

ファットコントローラーは、MVCアーキテクチャにおいて避けるべき状態なことを学びました。

上記の3つの解決策を意識すれば、ファットコントローラーになりづらいと思うので、

今回学んだことを活かし、今後の開発に役立てていきたいと思います。