PHPフレームワークではどこに処理を書くべきなのか

Question

自分はプログラミングを初めてまだ日が浅いのですが、例えばlaravelのようなフレームワークを使う場合に大体の処理をコントローラー内に書いてます。ですが上級者？の方のソースを見ると大抵クラス分けしてコントローラーではそのクラスを呼び出すような形でコードを組んでるみたいです。これってやっぱり自分もクラス分けして書いた方がいいのでしょうか。個人的にはコントローラーに書いた方が処理がまとまってて見やすいんですが、クラス分けにすることでなにか利点があるのでしょうか？

Answer 1

CakePHP 及び Laravel タグが付いていますから、それらのフレームワークにおける処理の共通化について回答しておきます。

目的

コントローラーに直接処理を記述せずに、他のクラスに処理を記述するのは、「他のコントローラーとの共通の処理を1箇所にまとめる」ためです。
また、特定の処理ごとにクラスを分けることにより、クラスの役割が明確化され、プログラムの可読性が上がります。
例えば、コントローラーに全ての処理が、クラスを使わずにズラーっと記述されていて、1メソッド100行を超えるような状態になっていた場合、非常に読みにくいですよね？
また、ログイン処理の修正が発生したとき、複数のコントローラーを修正する必要が出てくるため、工数の増加やバグの温床になりやすいです。
それが、クラスに記述していると、コントローラーをパッと見るだけで、大体そのコントローラーが何をやっているのかがわかるようになってきます（きちんとクラス設計されている前提）。

CakePHP 及び Laravel には、そのための仕組みが存在します。

CakePHP

コントローラ間で共有されるロジックのパッケージの仕組みとして、「コンポーネント」が存在します。
フレームワークで用意されているコンポーネントもあり、それを使えば一般的な処理は簡単に追加できますし、自分で独自のコンポーネントを作成することもできます。
詳しい利用方法はこちらを参照してください。

Laravel

コントローラ間で共有されるHTTPリクエストをフィルタリングする仕組みとして、「ミドルウェア」が存在します。
こちらも、フレームワークで用意されているミドルウェアもあり、それを使えば一般的な処理は簡単に追加できますし、自分で独自のミドルウェアを作成することもできます。
詳しい利用方法はこちらを参照してください。

フレームワークの仕組みを利用するメリット

composerなどを利用し、オートロード機能を使えば、独自にクラスを定義してフレームワークに組み込むことも可能ですが、フレームワークを利用するのであれば、フレームワークの規格に則った実装をすべきです。
フレームワークを利用するメリットの一つに、フレームワークの記述ルールをチーム内で共有することで、プログラムの品質及び開発効率をあげられる、というのがあります。
それが、わざわざ高い学習コストを払ってフレームワークを習得する意義なのです。
なので、フレームワークを使用する以上は、こういった仕組みを最大限利用し、外部のライブラリやフレームワークに準拠していないクラスを使用する場合でも、フレームワークに準拠したクラスによってラップするなどし、他の開発者に理解しやすい状態を保つことが大事だと思います。

Comments

[退会済みユーザー]

なるほど、クラス分けはフレームワークの仕組みを最大限使うことにもつながっていたわけですね。長文かつ丁寧に教えていただき感謝です。

Answer 2

コントローラにビジネスロジックを書いてしまうと、いわゆるファットコントローラと呼ばれる状態になってしまい、コードの見通しが悪くなったり等様々な弊害が生じます。数十行程度のメソッドならまだファット(太っている)とは言えないかもしれませんが、機能追加等をしていくと徐々にファットになっていってしまう可能性があります。このファットコントローラを改善する様々な手法がありますので、ファットコントローラをキーワードにして調査なさってみてはいかがでしょうか？

最後に私の好きなスライドへのリンクを置いていきます。スライド

Comments

[退会済みユーザー]

なるほど、ファットコントローラーなんて言葉があるんですね。調べてみます！

Answer 3

Class分けすることによるメリットは

• 他Controllerでも同じ処理を呼び出すことができる。
• 影響範囲をある程度絞ることができ、処理の修正や障害発生時の調査がしやすい。
• テストが行いやすい。
• ログなどの処理をかませたい！などといった時に、Classなどで処理が共通化されていると一括で処理をはさみこめる。
• 継承などを利用することで拡張性も向上する。

といったところでしょうか。

例えば、メール送信処理をControllerにべた書きしてしまうと、
他のControllerでもメールを送信したい！となったときに、他のControllerでも同じ処理をかかなくてはなりません。
更にそのメール送信処理の時にログを出したい！といったときも、各Controllerにログ出力のコードを書かなければならないです。

Comments

[退会済みユーザー]

確かに共通化されてると直すところも1箇所で済みますもんね。回答ありがとうございました！

Answer 4

ざっと概要みたいなものになってしまうのですが、クラスを呼び出すようなかたちというのは、おそらく

• 共通の機能をまとめて書いてあるか、
• 抽象的な機能をまとめて書いているか、

のどちらかに殆どの場合があてはまるのかと思います。
実際にアプリケーションを作るときには、特にここに厳密な規則はないのですが、何度も同じことを書くのはあまりよくないので使いまわせるものは使いまわしていこうという思想というか理想です。
開発している人たちも最終的にどのようなかたちで設計すればよいのかというのは、実は（細かな部分では）あまりわかっていなくて、開発をすすめるにあたって後から１つの関数やクラスにまとめたり、大掛かりなリファクタリングを行います。
コントローラーにいろいろ書くことは問題ではないのです。たぶんいろいろ書いているうちに「これは別のクラスにして後から使いまわせた方がいいなぁ」とか切に思うときがあるので、そのときにはっきり意味がわかってくるのかと思います。

DIとかトレイトとかファサード（DIの一種ですかね。。）とか、いろいろあります。
とはいえ、アプリケーションの規模や開発者の人数、また開発計画（おそらく大規模な開発だといっぺんにこしらえることはできないので段階的に計画的に開発したりすると思います。）などに設計自体も左右されるかと思います。

Comments

[退会済みユーザー]

やはり共通の機能は文字通り共通させた方が便利ですよね。抽象的な機能というのは例えばどういったものでしょうか？