自分がエンジニアバイトをしているところでは週1回Rails勉強会をしています。今回はそのやったところのまとめを残しておきます。
参考書：[現場で使える Ruby on Rails 5速習実践ガイド]
(https://www.amazon.co.jp/%E7%8F%BE%E5%A0%B4%E3%81%A7%E4%BD%BF%E3%81%88%E3%82%8B-Ruby-Rails-5%E9%80%9F%E7%BF%92%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89-%E5%A4%A7%E5%A0%B4%E5%AF%A7%E5%AD%90/dp/4839962227)
コードを書く場所を意識する
アプリケーションを作る上で何のコードをどこに書くかはとても重要になってきます。開発が進むにつれ、様々な機能を実装するためコードの量が増え複雑になっていきます。そこで少ないコストで全体を把握するには「 コードを書く場所を意識する」ことが重要になってきます。
コントローラに書くべきコード
RailではMVCを採用しています。それぞれに役割を持たせることで、どこが何をするところなのかを分けて管理しやすくしています。その中でコントローラの役割は送られてきたリクエストに対して、適切なレスポンスを返すのが仕事です。適切なレスポンスを返すためにModelやViewに対して働きかけます。
def index
@user = User.all
end
開発初期の頃は上記のようにとてもシンプルなコントローラですが、開発が進むとModelに書くべきビジネスロジックが増え、どんどん複雑さが増してしまうことが多くなります。そのためコントローラはModelから値を取り出したり、保存したりする計算処理(ビジネスロジック)をあくまで呼び出す処理に集中する必要があります。
検索条件を書いたコード
User.where(name: "Bob")
のように(短いですが)DBから検索をかけるようなコードの場合、コントローラに書くのではなく,Modelにscopeとして書く必要があります。
オブジェクトのデータを変更させるようなコード
@user.name = "Tom"
上記のようなオブジェクトがもつデータの変更がおきているコードの呼び出しが多数ある場合、その部分はModelに移したほうがよいでしょう。例えば、「ユーザーの情報を変更するメソッド」のような統合的なメソッドをModelに作り、コントローラ側で呼び出すだけにするとコントローラはスッキリしたものになります。