目的
最近、業務でなんとなくメソッドを使用していたが
自作する機会も増えてきた
しかし、メソッドを記述する場所を迷ってしまうため
アウトプットして、記憶に定着させる
しかるべきところにコードを書く
おなじみ、書籍 現場Rails 10-7 より抜粋
Railsが標準的に用意しているコントローラー、モデル、ビュー、ヘルパー、
ルーティングといった代表的な場所について、(比較的)適切な場所を選ぶことが重要だと
いうことを指しています
コントローラー
コントローラーの役割は、クライアント(ユーザー)から受け取ったリクエストを
適切にレスポンスを返すための窓口を担う
一般的に、
リクエストをもとにモデルのビジネスロジックを呼び出して
その結果をビューに引き渡す
ユーザーのニーズを反映していけばいくほど、入力される情報が
複雑になっていく
モデルから値をとりだしたり、事前処理を行う必要がでてくる
画面とロジックが入り混じり、複雑で肥大
いわゆるfat controllerになりやすい
・ビジネスロジックを書いてはいけない
モデル
・取得したオブジェクトに対して
何かを行っているコードが何行もあれば、モデルに記述するべき
・モデルを介してデータベースとのやり取りを行い、
データを取得したり新しいデータを格納する
・コントローラーからデータの追加や変更・削除の指示を受け実行
・モデルに寄せるのは、主に永続化に関わるものや、
単一モデルの操作で完結するビジネスロジックを優先的に寄せるイメージ
・基本は、ビジネスロジックを記述する
ビジネスロジックとは
データに対する処理などを行うプログラム処理のこと
テーブルとのやりとりに関するメソッドはモデルに置くという意識が必要
コントローラーはあくまで、モデルの機能を利用し処理を呼ぶ
だけで、複雑な処理は組まない
ビュー
こちらも、ビジネスロジックを含んではいけない
なぜなら、
・見せ方に対する変更が意図せず、
ビジネスロジック、またはプレゼンテーションロジックに影響を起こす可能性がある
・同じビジネスロジックが重複して存在するようになりやすい
ビジネスロジックを変更するときに、影響範囲が広く大変
・テストがビューを介してでしか、行えなくなる。
複数のビューで同じビジネスロジックがあったとしても、ビューの数だけテスト
しなくては、正しいことを保証ができないため
プレゼンテーションロジックとは
入力のためのフォームのようにユーザーとコンピュータを繋ぐために
ビューに書かれたコードをプレゼンテーションロジックという
ヘルパー
・ビューをよりシンプルに書くためのモジュール
・ビュー側で使うような見た目に関するものはヘルパーで実装する
・Viewでの共通する処理をメソッドとして定義し、簡単に使いまわせるようにした機能
参考記事、書籍
現場Rails
https://qiita.com/sumin/items/24689d0a5622f000a71f
https://qiita.com/kanekomasanori@github/items/daf93f95c77c629d070f
https://qiita.com/os1ma/items/25725edfe3c2af93d735