[Rails]Model/テーブル設計で必ず覚えておきたいSTI
開発チームの下田です。
Ruby on Railsについて、基本的なこと(modelやcontrollerが何か知っている程度)を理解されている方を対象としています。
BtoBクラウド受注・発注システムCORECはRailsで開発しています。
開発初期のコードを見直してみると失敗したなと思うことがあります。
中でも特に開発効率に影響しているなと思うのが、RailsのActiveRecordのSTI(Single Table Inheritance、単一テーブル継承)を活用しなかったことです。
STIを簡単に言うと、モデルを永続化するときに、どのクラスなのかというメタ情報を含めてデータベースに保存します。
これだけではわかりづらいと思うので、失敗した例と改善例からご紹介したいと思います。
悪い設計
仮に下記の仕様のコードを書くとします。
要件1:
CORECではWEBアプリから発注書を送信できます。送信方法は次の3つから選べます。
- WEBアプリ内で送信する
- メールで送信する
- FAXで送信する
この時、次のようなコードにしていました。
(項目名、メソッド名は意味が通じるように和名にしています)
# 注文書model
class Order < ActiveRecord::Base
include FAX送信モジュール
validates :送信方法, :presence => true
# WEBで送信するなら送信先IDが必須
validates :送信先ユーザ_id, :presence => true, if: ->{ 送信方法 == 'WEB' }
# メールならメールアドレスが必須
validates :メールアドレス, :presence => true, if: ->{ 送信方法 == 'メール' }
# FAXならFAX番号が必須
validates :FAX番号, :presence => true, if: ->{ 送信方法 == 'FAX' }
has_many :FAX送信結果
def 送信する
self.送信済 = true
validate!
case 送信方法
when 'メール'
注文Mailer.メール注文書送信.deliver
when 'FAX'
FAX送信する
end
save
end
private
def FAX送信する
FAX送信結果.create(送信結果: FAX送信モジュール.送信)
end
end
何が問題か
当初は送信するときだから、送信手段ごとに処理をcase-whenで振り分けることに違和感はありませんでした。しかし、開発を進めていると、同じコードがあちこちに現れて読みづらいコードになり始めました。
要件2:
- FAXは送信に失敗することがあるので、結果判定をする
- WEBとメールは必ず成功したとみなす
class Order < ActiveRecord::Base
# ~~ 略 ~~
def 送信成功?
# メソッドごとに送信方法による分岐がある状態
case 送信方法
when 'FAX'
FAX送信結果.送信成功?
default
true
end
end
end
あるべき姿
FAXもメールもすべて注文書の情報なのでOrderクラスにしたことは正しいのですが、送信方法によってふるまいが違います。役割が同じでふるまいが違うなら、サブクラスを作りポリモーフィズムを持たせるべきです。
class Order < ActiveRecord::Base
def 送信する
self.送信済 = true
save
end
def 送信成功?
false
end
end
# WEBで送信する注文書クラス
class Order::Web < Order
validates :送信先ユーザ_id, :presence => true
def 送信する
validate!
super
end
end
# メールで送信する注文書クラス
class Order::Mail < Order
validates :メールアドレス, :presence => true
def 送信する
validate!
注文Mailer.メール注文書送信.deliver
super
end
end
# FAXで送信する注文書クラス
class Order::Fax < Order
validates :FAX番号, :presence => true
has_many :FAX送信結果
def 送信する
validate!
FAX送信する
super
end
def 送信成功?
FAX送信結果.送信成功?
end
private
def FAX送信する
FAX送信結果.create(送信結果: FAX送信モジュール.送信)
end
end
メソッドの中から冗長なcase文が消えます。また、relationやvalidationのふるまいも送信方法ごとに整理され、見通しが良くなりました。
このようなクラス設計にしたい場合はSTIを使用します。STIを使用するにはtype:stringカラムを追加します。
create_table "orders", force: true do |t|
t.string "type" # 追加するとSTIになる
t.integer "送信先ユーザ_id"
t.string "メールアドレス"
t.string "FAX番号"
t.datetime "created_at"
t.datetime "updated_at"
end
typeカラムがある場合とない場合を比較してみましょう。
# typeカラムがない場合
order = Order::Mail.new(メールアドレス: 'hoge@example.com')
order.save
# id: 1
# メールアドレス: "hoge@example.com"
# OrderからロードするとOrderになる
Order.find(order.id)
=> #<Order id: 1, メールアドレス: "hoge@example.com">
# Order::MailからロードすればOK
Order::Mail.find(order.id)
=> #<Order::Mail id: 1, メールアドレス: "hoge@example.com">
# typeカラムがあり、STIになっている場合
order = Order::Mail.new(メールアドレス: 'hoge@example.com')
order.save
# type: 'Order::Mail' # クラス名がtypeに自動的にsaveされる
# id: 1
# メールアドレス: "hoge@example.com"
# created_at: 2015-01-01 12-34-56
# updated_at: 2015-01-01 12-34-56
# Orderからロードしても、きちんとOrder::Mailになる
Order.find(order.id)
=> #<Order::Mail id: 1, メールアドレス: "hoge@example.com">
# サブクラスからロードすると、typeを検索条件に自動で加えてくれる
Order::Mail.all.to_sql
=> "select * from orders where type = 'Order::Mail'"
データベースに保存し永続化した後でもふるまいを維持し続けてくれるので、クラス設計を適切に行えば複雑な仕様が追加されても、良い状態のコードを保てると思います。
運用上の注意
開発には非常に便利なSTIですが、運用を考えて開発しなければならないことが1点あります。typeカラムに存在しないclass名が設定されていると、ActiveRecord::SubclassNotFound例外が発生します。
ActiveRecord::SubclassNotFound例外が発生するのは、2パターンがあります。
- リリース時に並行稼動している時に、新しいAPで保存した新しいサブクラスを古いAPでロードした
- リリースしたがロールバックし、新しいAPで保存した新しいサブクラスを古いAPでロードした<
どちらの場合も、何も変更しないサブクラスを作り、先行してリリースしておくと、予期せぬ例外が起きません。フェイルソフトになります。
# 仮置きする。
class Order::NewClass < Order
end
もしくはデフォルトスコープに現バージョンで存在しているclassのみを指定すると、ロードされないので例外が発生しません。サブクラスを追加した時に追加し忘れたり、where句が思わぬところで効いたりしないか確認が必要です。
class Order < ActiveRecord::Base
# 条件に加えてしまう。
default_scope ->{ where(type: [Order, Order::Corec, Order::Mail, Order::Fax]) }
# ~~ 略 ~~
end
おわりに
STI以外にも、ああすればよかったと思うことは多くあります。その中でもSTIについて書いたのは、知っているか知らないかでModelの設計に差が出てしまうため、気づいた時には手軽にはリファクタリングできなくなっているからです。その反面、ある程度の規模のアプリケーションでなければ使い道が無くRuby on Rails チュートリアルに載っていなかったりと軽視されがちです。
新しくmodelを設計するときには頭の片隅に置いておくといいと思います。
