はじめに
RailsのMVCモデルのC(コントローラー）について、少し踏み込んだ内容をアウトプットしていきたいと思います。
よろしくお願いします。
コントローラーの役割とAction Controller
コントローラーはルーティングによって振り分けられたリクエストを受け取り、モデルやビューに命令をしている司令塔みたいなものです。最終的にレスポンスを返しているのもコントローラーですが、この機能はAction Controllerという仕組みが働いているからです。
ビューにもAction Viewってのがありましたね。
Action ControllerはRailsのコントローラーの機能を実現させているオブジェクトです。
可読性を意識する（メソッドの切り出し）
コードを書くときには可読性を向上し、わかりやすく、すっきりとしたコードを書くことに努めるべきですよね。
Viewのときにも、複雑なRubyの処理はビューファイルに書き込むより、モジュールとして切り出したりしてコードを読みやすくできることを説明しました。
コントローラーにもあまり、長文で複雑な処理を書くのは好ましくありません。コントローラーは司令塔の役割をしているので、できれば処理をするよりは、何を受け取っていて、レスポンスで何が返されているのかが明確であるべきです。
そのために、そういったデータを扱う複雑な処理はモデルに切り出してあげることがポイントになります。
サービスクラス
複雑な処理は、できればモデルに切り出すということをお話ししました。しかしながら、規模が大きなアプリケーションになれば、モデルの記述量も多くなってきて、肥大化しやすいという注意点が存在します。
そこでサービスクラスにコードを切り出してあげます。
サービスクラスとはコントローラーのコードの可読性を高めるために用いる概念です。
というのが、よくある説明なんですが！クラスに分ける理由はもう一つあります！むしろこっちの方を理解せずにサービスクラスにコードを分割すると実際の現場では大変なことになるようです！
クラスに分けたい一番の理由は、アプリケーションの改修などが行われる際に、一つのモデルが膨大な量のインターフェイスを抱え過ぎた結果、変更範囲が確定できなくなることを防ぐために切り出すのだそう。
もし、モデルが肥大化したとしても、構造が安定し、インターフェイスが明確で変更することがないのであれば、問題にならないとのこと。
こちらの記事で詳しく書かれていたのでぜひ読んでみてください↓
こちらの記事でおっしゃっておられますが、サービスクラス云々の前に、オブジェクト指向というものにしっかりと向き合っていかなければならないそうです。
最後に
コントローラーについて深ぼっていたら、サービスクラスという概念が出てきて、そこには大きな落とし穴がありました。
もし新しい概念や手法が出てきたときに無理に使うのではなくて、なぜ使うのかよく理解してから使わなければならないなあと痛感しました。反省です。