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
このようにリソースを考えることは、主に設計の好みの問題であり、要件に応じてトレードオフがあります。