0

私は2つのモデルを持っています

  1. ShippingClass は、配送料と配送料が適用される宛先を定義します
  2. いくつかのアクションを許可するかどうかを決定するステート マシンを持つショップ

ショップには多数の配送クラスがあります。ユーザーは配送クラスを追加または削除できます。また、他の要因の中で、少なくとも 1 つの shipping_class が存在するかどうかがショップの状態に影響を与えます。

肝心なのは、配送クラスが追加/削除/変更されるたびに、ショップモデルで update_state メソッドを実行して、状態を最新に保つことです。このメソッドが行うことは基本的に、ショップに関連付けられている shipping_classes の数を確認し、それに応じてショップのステータスを調整することです (たとえば、ショップの状態を単純化するために、少なくとも 1 つの shipping_class が割り当てられている場合はアクティブであり、そうでない場合は非アクティブです)。

コントローラーからショップの状態を更新するのが良い方法かどうか疑問に思っていました。私は実際、ShippingClass を保存および破棄時に Shop を更新する機会を評価しています。これは、ShippingClass を保存するたびに Shop モデルを更新することを覚えておく必要がないため、エラー防止にはなりますが、モデルの結合は増加します。

これを行うためにコールバックを使用することはオプションではないようです。これらはトランザクションにラップされます。したがって、親モデル (Shop) は、トランザクションが完了する前に、関連付けられたモデル (ShippingClasses) の状態が正確にわかりません。

編集 以下で指摘するように、別のオプションは、モデルの更新をオブザーバーに配置することです。これの利点は、トランザクションにラップされないことです。そのため、Shop モデルは関連する ShippingClasses をチェックできるはずです。欠点は、トランザクションにラップされていないことです。そのため、Shop モデルの更新に失敗すると、Shop ステータスが非同期になります。ただし、これは更新をコントローラーに配置するよりも優れています。

別のオプションとして、ShippingClass の save メソッドと destroy メソッドをオーバーライドし、そこから Shop モデルを更新することもできます。

ベストプラクティスとその理由は何ですか?

前もって感謝します

4

1 に答える 1

0

ご指摘のとおり、コントローラーが ShippingClass を変更/削除/追加しようとするたびにロジックが適用されるため、ロジックをモデルに保持するのが最善です。モデル内では、ShippingClass でコールバックを使用するようにします。ShippingClass は、変更/削除/追加操作の結果として影響を受けるショップの状態を更新します。

于 2012-07-03T12:39:59.787 に答える