1

私の Rails アプリでは、次CASEのように、ケース固有のドメイン モデル (つまりCASEA、CASEB、CASEC)の論理スーパー クラスとして機能するドメイン エンティティがあります。

               +--------+
               |  CASE  |
               +--------+
                    ^
                    |
      +-------------+-------------+
      |             |             |
  +-------+     +-------+     +-------+
  | CASEA |     | CASEB |     | CASEC |
  +-------+     +-------+     +-------+

アイデアは、すべてのケースに共通のプロパティを持つ 1 つのドメイン モデルと、そのケースに固有のプロパティをカプセル化する特定のケース タイプごとに 1 つのドメイン モデルを持つことです。

各特定のケース インスタンス ( ) が 1 つのケース インスタンス ( ) のみを参照する必要がある双方向の 1 対 1 の関係を使用して、複数テーブルの継承設計を実装する必要があります。逆に、各インスタンスは、ケース固有のインスタンスを 1 つだけ参照する必要があります ( )。それぞれの特定のケースは異なるドメイン モデル クラスであることに注意してください。さらに、保存、更新、削除を次のように相手側にカスケードするために、CASEを関係の所有者にしたいと考えています。CASEXCASECASECASEX

case = Case.new
case.case_info = CaseX.new
case.save!
# both case and CaseX are validated and saved

アクティブ レコードを使用してこの関係を実装するには、どのような方法が最適でしょうか?

4

2 に答える 2

1

あなたが説明していることは、単一テーブル継承 (STI) の強力なユースケースのように聞こえます。これは文字通り、3 つの特定のケース (A、B、C) にわたるすべての属性のスーパーセットを持つ 1 つのテーブルがあり、Rails が正しいものをプルすることを知っていることを意味します。

これをよく説明している 1 つのブログ投稿は次のとおりです。

http://blog.eizesus.com/2009/10/sti-best-practices-in-rails/

ただし、状況によって異なります-上記のリンクの「悪い例」は、属性間の重複がないため悪いです。オーバーラップが比較的多い場合は、STI が有利な場合があります。

別のテーブルを使用する場合は、ケース モデルとサブケース モデルの間の has_many/belongs_to 関係を見ています。特定のケース タイプの 1 つだけが存在することを確認するために、Case オブジェクトのカスタム検証メソッドが必要になる場合があります。

于 2012-12-14T17:40:22.003 に答える
0

私が実際に望んでいるのは、ある種の複数テーブルの継承です。周りを見回すと、ポリモーフィックな関係を使用してソリューションを実装する方法を説明するこの記事を思いつきました。それはまさに私たちが達成したいことです。

http://mediumexposure.com/multiple-table-inheritance-active-record/

于 2012-12-14T18:59:29.250 に答える