自分がエンジニアバイトをしているところでは週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)
Viewの役割
Viewはプレゼンテーション層もしくはユーザー・インターフェース層とも呼ばれています。役割としてはユーザーとコンピュータをつなぐ役割をしています。具体的にはページの表示、ページ遷移、ユーザーが入力、操作したことをコンピュータに伝えるのが役割です。このユーザーがページを見るためのコード、入力のためのフォームのようにユーザーとコンピュータを繋ぐためにViewに書かれたコードをプレゼンテーションロジックといいます。
Viewにビジネスロジックが混ざることの問題点
-
Viewに同じビジネスロジックが重複してしまい、変更範囲が広くなり変更にコストがかかってしまう。
→ Modelに記述しておけば変更時は一箇所だけになるので管理が楽になる。 -
Viewを介してテストを書く必要が出てくるので、同じビジネスロジックの場合全てテストするのは手間がかかる。
→ Modelに書けばテストは一つですむ。 -
デザインが頻繁に変更される場合、ビジネスロジックにその変更による影響がでることがある。
なのでViewとModelの関係はModelからデータを受け取るだけにしておきたい。