私は、モデルとそれが関連しているRESTfulなアプローチがいつ適切なのか、そうでないのかをいつ知るべきかについてのガイドラインを探しています。おそらくそれは私の現在のアプリケーションの性質ですが、関連がないシンプルなモデルはRESTとうまく機能していますが、多くのhas_manyアソシエーションを持つ複雑なモデルは実際にコントローラで必要なビューとセットアップを複雑にしています。 form_for呼び出しは特に複雑になり始めます。いつRailsアプリケーションでRESTfulコントローラを使用するべきですか？
それとも私の新生児の理解です。私は3年以上にわたってRailsをやってきましたが、RESTと一緒にヘルパーを構成すると、私を神秘的に見せかけています。
システム内の各トップレベルモデルのリソースを作成します。トップレベルでは、私は独立しており、関連するモデルの外で意味を持つモデルを意味します。一般的に、それはほとんどのモデルです。次の例では、位置と候補は最上位です。あなたは、候補者が過去の雇用と彼女が適用したポジションで構成されると考えることができます。求職者への応募書類や過去の履歴書は、候補者のリソースを通じてアクセスすることができます。候補者自身は存在しないためです。
モデル
class Position
has_many :candidate_positions
has_many :candidates, :through => :candidate_positions
end
class Candidate
has_many :candidate_positions
has_many :positions, :through => :candidate_positions
has_many :past_employments
accepts_nested_attributes_for :past_employments
accepts_nested_attributes_for :candidate_positions
end
class PastEmployment
belongs_to :candidate
end
class CandidatePosition
belongs_to :candidate
belongs_to :position
end
ルート
map.resources :positions
map.resources :candidates
モデルにまたがるユーザとの相互作用のための非機知コントローラを使用。たとえば、利用可能なポジションと最近の候補を表示するHomeControllerを作成する場合は、これは新しい単純なコントローラーになります。このコントローラーの情報を編集したい場合は、クール！フォームの投稿を処理するためのコントローラが既に用意されています。これは自動的に<% form_for @candidate %>と配線されます。 <%= render @positions %>であなたの位置のコレクションをレンダリングすることができます。そして、それらをリソースにしたので、Railsはviews/positions/_position.html.erbに適切な部分を探します。
最終的には、複数の場所でオブジェクトの永続性を処理するロジックを書くことはないはずです。コントローラーが複雑になり、フォームが手に入らなくなります。また、Railsと外部システムは、オブジェクトの検索と格納の場所を知っています。同じURL、同じコントローラ、ちょうど異なるフォーマット。
私はRoRを知らないので、RESTでgenerate文を作成します。
RESTとROIはURLを一連の名詞として扱い、GET、POST、PUT、DELETEなどのHTTPメソッドを動詞として使用します。このモデルはCRUD、複数の関連を持つモデルの場合でも有効です。 URLはリソースを表すので、関連オブジェクトはURLのリストとして表現できます。
しかし、検証、移動、コピー、ホック、読み込み、書き込みなどの細かい動詞が必要な場合は、RESTに適合しない可能性があります。
免責事項：私はレールを知っていますが、まだかなり初心者です。 短答：RESTとフォームヘルパーは全く異なる分野です。
長い回答： 私が理解しているように、Representational State Transferは、フォームとビューの実際のレンダリングと大まかに関連しています。
RESTは実際にはコントローラと特定のモデルを拡張する必要があります。クライアントとの会話全体を考えるのではなく、個々のクライアントメッセージに特定の予測可能な方法で応答するWebアプリケーションを作成するという考え方です。
つまり、クライアントがモデルを取得した場合は、取得してフォーマットし、送信して忘れてしまいます。 クライアントが何らかの更新をポストしている場合は、webappsの状態を反映させ、応答を返送して忘れてしまいます。将来のGETまたはPOSTは新しい状態を見ますが、それを作成したメッセージは見えません。
実際、アプリケーションがRESTfulであるかどうかは、実際にはモデルの複雑さではなく、ユーザーとのやり取りの方法によって決まります。少なくともクライアントに依存しない、つまりデータ中心のアプリは、RESTに適しています。セッションに大きく依存し、特定のユーザーと対話し、プロセス中心のものは、あまり良い候補にはならないかもしれません。
一方、Railsフォームヘルパーがあります。これらは足場に適していますが、より複雑な方法でそれらを使用しようとすると、時々イライラすることがあります。
あなたの主な質問は何ですか？ヘルパーを形成するレールについて特定の質問がありますか？レールコントローラについて？またはRESTに固有の何か？
あなたはRESTの文脈では約持って、多くの関係とフォームを話すRailscastsのこのシリーズ、チェックアウトすることがあります
を