0

厳格な REST 支持者は、CRUD ではないコントローラーでアクションを定義している場合は、新しいリソースを作成し、そのアクションを新しいリソースでの CRUD 操作として定義することを強く検討する必要があると言うかもしれません。

例として、モデルの状態を変更する操作 (購入など) が挙げられます。この例では、PurchaseController で「完了」アクションを定義する代わりに、CompletePurchasesController を作成し、作成アクションを使用して購入の状態を完了に更新することができます。

上記を仮定すると、明らかに PurchaseState をデータベースに直接永続化することはありません。

私の質問は、コントローラーをモデルに結合するのはいつですか? PurchaseState モデル (永続化されていない) を定義するのはいつで、単純に Purchase を直接操作するのはいつですか。

複雑さと、コントローラーのアクションで対話している疎に関連付けられたモデルの数の問題ですか?

4

2 に答える 2

0

購入状態を更新するには、おそらく PurchasesController update アクションのみが必要です。これは、routes ファイルで 'put' または 'patch' メソッドとして定義します。

更新時に発生するのが購入オブジェクトの状態フィールドの変更だけである場合は、更新アクションでそれを行うことができます。

状態遷移の一部に何らかのビジネス ロジックがあるが、最終的にその購入オブジェクトのみを変更する場合は、おそらくそれを Purchase モデルに入れたいと思うでしょう。

他のテーブルも更新された場合、または新しい購入を祝福するメールをユーザーにキューに入れるなどのことも行っている場合は、別の PurchaseComplete または PurchaseAbort モデル/サービス オブジェクトを追加すると思います。これらは、アクションのロジックがより複雑な場合、および/または複数のモデルに変更を加えている場合、または何か他のことを行っている場合に最も自然に機能するようです。

于 2014-04-24T21:13:22.217 に答える
0

「完了」は、(既存の) 購入時の状態遷移イベントです。このアクションを、購入モデルに結合されたコントローラー (実際には PurchaseController 自体) での更新アクションではなく、仮想リソースでの作成として概念化するのは直観に反すると思います。

このような状態遷移に対して、個々の更新のようなアクションを定義します。このようにして、モデルの初期化、ビューのディスパッチ、ルーティング、アクセス制御など、最も経済的な方法でレール構造を活用できると思います。単に追加するだけで、inherited_resources、cancanを使用すると仮定しましょう

# routes.rb
resource :purchase do 
  put :complete, :on => :member
end

# purchase_controller.rb
def complete
  @purchase.complete!
end

# cancan ability (entry already there for basic crud)
can :manage, Purchase, :user_id => user.id

UI全体の実装はすでに完了しています（ビュー/モデルロジックは別として）。レールでそれがどれほどクールか。

あなたの典型的なユースケースが、購入が状態遷移によってのみ更新される場合、特にすべてが同じアクセス権とリダイレクト ビューを持っている場合、state_event 属性を持つ PurchaseController の更新アクションを使用することさえあります。見る

誰かが pluginaweek - statemachine のアクティブなレコードの例を挙げてもらえますか?

厳格なREST主義者、私を噛んでください！:)

于 2012-05-12T02:35:27.523 に答える