2

私は、ActiveRecord エンティティとフィールドの一貫性を常に維持する必要があるシステムを開発しています。多くの場合、特定のフィールドは他のフィールドから派生し、常に最新の状態に保つ必要があります。場合によっては、これがエンティティ間で発生することさえあります。

例えば：

class User < ActiveRecord::Base
  attr_accessible :first_name, :last_name
  attr_protected  :name

  # I need to keep 'name' up to date at all times
  after_update do
    name = self.first_name + ' ' + self.last_name
    true
  end
end

ここでの哲学的な問題は、コールバックまたはオブザーバー内でこのタイプの動作 (および何百もの同様の動作) を実装する必要があるかどうかです。以下の両方を行う理由がいくつか考えられます。

コールバック

  • 動作の定義に簡単にアクセスできます (モデルの定義を見るだけで、どこを見ればよいかがわかります)
  • フィールド/エンティティ間の一貫性を維持することは、補助的な問題ではなく、エンティティの動作の複雑な部分です。実際、データの一貫性を維持することは、(暗黙のうちに) あらゆるエンティティにとって第一級の要件です。

オブザーバー

  • システムの動作が最終的により複雑になるにつれて、モデルはより軽量になる傾向があります (何百ものコールバック メソッドで肥大化することはありません)。
  • フィールド/エンティティ間の一貫性を維持することは補助的な問題であり、モデルの主な責任とは関係ありません。したがって、外部オブザーバーに分解する必要があります

もっと経験のある人が私に教えてもらえますか？

  • 私が調べていない特定の考慮事項はありますか?
  • コールバックとオブザーバーに属するものを決定する際のガイドラインは何ですか?
4

1 に答える 1

1

Design Patterns book によると、これは Observer パターンに最も適しています。Observer を使用すると、after_update/save ロジックがモデルから分離されます。あなたの例からはわかりにくいですが、コールバックから他のモデルを更新している場合、他のモデルの知識で User モデルを汚染しています。したがって、オブザーバーはそれを処理するために介入する必要があります。

また、Rails でオブザーバーを無効にできるため、「コールバック」がトリガーされることを気にしないユニット テストを高速化できます。

于 2012-09-27T18:15:49.053 に答える