Railsで便利にMVCを使用する

Question

私は、この時点で1つの更新アクションで著者、翻訳、関連記事などのすべての記事の関係を管理する記事コントローラを持っています。

ページには、検索とソート機能、CRDアクション、新規作成および既存の関連付けレコードの管理用フォームが含まれています。

これらのすべては、ArticleControllerの編集および更新アクションおよび各リスティングの部分テンプレートの束によって管理されます。

関連するレコードを検索するための検索テーブルを追加することで、機能をさらに拡張したいと考えています。そして、後で私はいくつかの他の機能を追加します。

私はこの方法（1つの編集ページ内のすべての関連付け管理）が便利ではないと感じています。だから、それぞれのリストにいくつかの特別なコントローラーをつくるのが良いでしょう：

/articles/1/edit/authors 

そして、このコントローラーの名前は何でしょうか？ ArticleControllerまたはPeopleControllerまたはApplicationControllerの子である必要がありますか？

または多分すべて大丈夫と私は偏執狂だ？）

すべてのMVCの条件が満たされているsctictly

UPD。質問は：

すべてのリレーションシップを1つのコントローラで管理するのは良いことですか？ @ article.authors.find_or_create_by_name（name）のように、リレーションを追加/削除するだけでなく、新しいものを作成することもあります。ビューの関係は単にタグを選択するのではありません！彼らは独自の検索、並べ替え、ページ設定機能を備えた完全に保護されたテーブルです。

は「サブコントローラ」を作成する方法：我々はArticleControllerは、その編集アクションを持っている場合、誰かが私を理解していけない場合

は、別の方法でお願いします。 ArticleControllerは記事モデルのフィールドのみを管理する必要があります。そして、多くのサブコントローラーが関係を管理する必要があります。

なぜ私はそれが必要ですか？ AJAXをそのようなページに追加することができます：深刻な問題はありませんが、AJAXのすべての呼び出しで、ArticleController.update/editアクションを実行して、モデルのArel関係を構築するなどの不運な作業を行うことがあります。私は仕事を小さな独立した部分に分け、1つの巨大なコントローラを構築するのではなく、すべてを行うことができます。

Answer 1

あなたの記事controllerは関係を管理すべきではありません。それはあなたのmodelにあるはずです。アクティブなレコードcallbacksを見てください。あなたは、コールバックであなたの作者、翻訳などを管理することに関連するすべてを行うことができます。たとえば、after_updatecallback

また、nested resourcesを使用します。たとえば、authorsは内部にネストされていますarticles

Answer 2

おそらく、投稿者< - >記事の関係を管理する著者コントローラを持つことができます。 「結合」モデルを使用して、関連する2つのモデル間の関係を処理できることを忘れないでください。 もちろん、関係の追加/削除の

edit_article_authorships GET /articles/:article_id/authorships/edit(.:format) {:controller=>"authorships", :action=>"edit"}