【Rails】について言葉でまとめてみた③ [デバッグ]・[i18n]・[decorator]・[アソシエーション]・[dependent: :destroy]・[DB側の制約(not null制約、外部キー制約)]

概要

言葉でまとめてみた③

[デバッグ]・[i18n]・[decorator]・[アソシエーション]・[dependent: :destroy]・[DB側の制約(not null制約、外部キー制約)]について言葉で説明できるようにする

言葉でまとめてみた①はこちら

言葉でまとめてみた②はこちら

[デバッグ]

デバッグでどんなことを確認するか?

変数の中身、メソッド戻り値、paramsに入っている値など

[i18n]

i18nとは何か。i18nについて、日本語と英語でページを出し分けるときに、localeという単語を使って、どの様に翻訳処理が行うのかを簡単に説明せよ。

Railsのアプリケーション内で複数の言語を併用する仕組み。

config/locales下にymlファイルを作成する。(英語であればen.yml、日本語であればja.yml)。userクラスにlocaleという属性を設定し、beforeアクションにてcurrent_userのlocaleを確認するメソッドを定義すればユーザーごとに言語を切り替えられる。

Railsガイド Rails 国際化 (i18n) API

[decorator]

decoraterは何のために必要か?

既存のオブジェクトをラッピング(包み込む)ことで、既存のオブジェクトを変更することなく、機能(メソッド)を追加したりできる。

Helperと何が違いますか?

decoraterはmodelに依存するロジックを書く。(last_nameとfirst_nameを合わせたfull_nameみたいな。)

user_decorator.rbboard_decorator.rbに同じ名前のロジックを使用しても問題ない。

Heplerはview全体に関係するようなものを書く。(ページのタイトルを動的に切り替える等のロジック。)

helperはグローバルなので、user_helper.rbboard_helper.rbに同じ名前のロジックを使用してしまうと、どっちのロジックを使用するのかRailsがわからなくなってしまう。

どのviewからも使用できるように。

ロジックをViewに書くことの問題点は何でしょうか?

ロジックをviewに記述するとviewファイルが肥大化(fat化)し、可読性が低下する。

[アソシエーション]

アソシエーションの定義をモデルに書くと、具体的にどの様な変化があるか?

メソッドチェーンを使用して他のモデルの値を取ってこれるようになる。

ex)

#Board.where(user_id: user.id)が以下の1行で持って来れる
user.boards

UserモデルとPostモデルがあるとした場合、1人のユーザーは複数の投稿できるので、Userモデルにhas_many: postsと記載する。 逆に1つの投稿は1人のUserが所有するので、Postモデルにbelongs_to :userと記載する。

Railsガイド has_manyで追加されるメソッド

[dependent: :destroy]

dependent: :destroyの使い方

モデル間のリレーションが設定されている場合、この設定をした親モデルが削除される時、関連する子モデルも同時に削除され、参照先が存在しないというバグを防ぐ。

UserとPostモデルがあるとした場合、1人のユーザーは複数の投稿ができるので、Userモデルにhas_many :posts, dependent: :destroyと記載する。

Railsガイド 4.3.2 has_manyのオプション

[DB側の制約(not null制約、外部キー制約)]

モデルのバリデーションだけでなくDBの制約もかけたほうがよい理由を説明せよ

SQLから直接データを入力するとバリテーションをすり抜けて登録されてしまうから。