ビジネスロジックを記述するモデルはソースコードが複雑になりやすいです。下記の方法でモデルのソースコードを共通化して簡素化する必要があります。
- 共通処理をモジュール化しモデルにMix-inする。
- クラスの継承を行う。
- 共通処理を担うオブジェクトを別に作って連携させる。
共通処理をモジュール化しモデルにMix-inする。
下記のような感じで記述します。
|
1 2 3 4 5 |
module モジュール名 extend ActiveSupport::Concern #共通メソッド群 end |
extend ActiveSupport::Concern
RailsでMix-inのためのモジュールを記述する時によく使われる記述になります。普通のRubyクラスのモジュール化に比べて書きやすくしてくれます。このコードは「app/models/concerns」ディレクトリに配置します。
クラスの継承
STI(単一テーブル継承）により共通機能を基底クラスに持たせる。
Railsでは継承関係にある一連のモデルクラスを1つのテーブルに紐付けます。これをSTIと呼びます。非常に便利ですが下記のデメリットもあります。
STIのデメリット
- データが一つのテーブルに集中するので処理速度低下の原因となる場合がある。
- クラス名変更のたびにDB内のtypeカラムを変更しなければならない。
- クラスのデータ構造の差異が大きい場合はDB利用効率が悪くなる。
STIを使った方が良い場面
- クラス同士の関係が「AはB」の1種類である場合
- STIとして共有する各クラス間でカラムに大きな差異がない場合
- まとめるクラス同士が似ている場合
ApplicationRecordに共通処理を記述する。
Rails内の全ての共通の振る舞いをApplicationRecordに記述できます。（全てのクラスにおいて共通のため）
利用例
- DBへの操作を常に記録すr。
- ActiveRecord::Baseの動作を上書きする。
- モデル全体で使えるDSLを定義する。
全てのモデルにおいて共通の振る舞いのみここに記述するようにしましょう。でなければ意図しない動作をしてしまいかねません。
中間的なクラスを作って一部のクラス群だけ共通化する。
ApplicationRecordと実際のモデルクラスの中間的なクラスを作れば一部のクラスにだけ継承させれます。
|
1 2 3 4 |
class 一部だけ共通化するクラス < ApplicationRecord self.abstract_class = true #共通処理 end |
その際は、継承専用クラス(抽象クラス)としてself.abstract_class = trueと記述するようにしましょう。
この記事へのコメントはありません。