単一テーブル継承とRailsでの使用場所 質問する

単一テーブル継承とRailsでの使用場所 質問する

私は奇妙なデザイン問題に陥っています、

私は2種類のプロファイルモデルに取り組んでいます。

  • ユーザープロフィール(ユーザーに属する)
  • その他は「ボット」としてサイト内で維持されています(誰にも属していません)

これら 2 種類のプロファイルの一般的な OO 動作は同じですが、重要な属性/プロパティのみが共通であり (非常に重要なものは 5 ~ 6 個)、「興味など」などのその他のプロパティ (約 10 ~ 15 個のプロパティ) はボット プロファイルにはありません。

以前これに取り組んだコーダーは、ボット プロファイルとユーザー プロファイル用に別々のモデル/コントローラーを作成したため、あらゆる場所で多くの冗長性が生じ、予想どおり保守やテストの作成などが困難になりました。私は、少なくともこれらの冗長性の問題の一部またはすべてを解決するために、これを DRY 化したいと考えました。

解決策としてシングルテーブル継承を提案した人がいました

代わりにポリモーフィック関連付けを使用することを提案する人がいました。

より良いアプローチは何でしょうか。STI は実際にいつ使用するのでしょうか?

私自身の考えでは、モデルの属性は同じで動作が異なる場合に STI が最もよく使用されます。

何ができるか考えていますか?

ベストアンサー1

STI は、属性は同じだが動作が異なる場合に最も役立つと特徴付けるのは「ほぼ正しい」ですが、少し制限があるかもしれません。名前が示すように、異なるタイプのオブジェクト間のデータベース スタイルの関係ではなく、明確な OO スタイルの継承関係がある場合に、私は STI を使用することを好みます。

ボットとユーザーの間に共通のコードがある場合、STI が最適だと思います。共通の属性がいくつかあるだけの場合は、適用性は低くなりますが、試してみる価値はあります。

私はかなり実験的な人間なので、試してみることをお勧めします。コードを分岐し、モデルを STI 関係にリファクタリングします。本当に問題が解決するのか、それとも頭痛の種が別の問題に置き換わるだけなのかを確認してください。

コントローラーを乾燥させても、あまりメリットがないと思うことの 1 つです。私の経験では、STI モデルは、同様の関連コントローラーに変換されることはあまりありません。しかし、それは別の実験になります。うまくいくときもあれば、うまくいかないときもあります。

おすすめ記事