QuestionsController
これは、新しいリソースの豊富なメンバールートを:に追加することが実際に正当化される数少ないケースの1つである可能性があります。
resources :questions do
post 'answer', :on => :member
end
question/:id/answer
これは、にルーティングされたPOSTリクエストで認識し、questions#answer
すべてのロジックを1つのコントローラーに保持できるようにします。
class QuestionsController < ApplicationController
...
def show
@question = Question.find(params[:id])
end
def answer
@question = Question.find(params[:id])
@answer = @question.answers.build(params[:question][:answer])
if @answer.save
# show question with newly posted answer at url /question/:id
redirect_to @question
else
# show question with invalid editable answer at url /question/:id/answer
render 'show'
end
end
...
end
説明:私の意見では、2つではなく1つのコントローラーでロジックを処理するという決定は、関心のあるリソースであるとみなすものに帰着します。通常、各モデルは個別のリソースを表すと見なし、各リソースに関連するアクションを処理するための個別のコントローラーを作成します。show
ただし、複数のアクション( 、、new
など)が単一のビューで処理される複数の深く結合されたモデルがある場合、モデルを単一のリソースcreate
を形成していると考える方がクリーンな場合があります。
この例では、リソースを質問とその回答の両方で構成される集合的なリソースと考えています。この集合的なリソースは質問自体によって一意に識別されるため、質問コントローラーに処理させます。show
質問コントローラーのアクションには、集合的な質問と回答のリソースの取得がすでに含まれているため、answer
アクション(および場合によってはアクション)unanswer
をその集合的なリソースreanswer
の類似物と考えることができます。update
このようにリソースを考えることは、主に設計の好みの問題であり、要件に応じてトレードオフがあります。