railsのルーティングの階層構造について

Question

最近勉強を初めて自分でWebアプリケーションを作ろうと手をつけ始めました。
初学者のため、基礎が分かっておらず、ネットで探しても中々思うような記事が見つからず、ご教示いただけると嬉しいです。

◾️知りたいこと
railsのRoutes.rbファイルにおいて、ネストをさせる場合の基本的な考え方。

◾️事例
なんちゃってブログ（Webアプリケーション）を作ろうと思ったとします。
想定されるモデルは以下の通り。

【モデル】
①Userモデル（ユーザ）
②Blogモデル（ユーザのマイページ）
③Postモデル（投稿）
④Commentモデル（投稿に対するコメント）

　それぞれ以下のようなアソシエーション。
【アソシエーション】
①(has_one) -②(belongs_to)
①(has_many)-③(belongs_to)
①(has_many)-④(belongs_to)
②(has_many)-③(belongs_to)
③(has_many)-④(belongs_to)

　何となく短絡的に、こんなルーティングネストを書きたくなります。

　resources :users do
　　　resources :blogs do
        resources :posts do
           resources :comment
        end
     end
   end

　commentのshowをしようと思ったら、パスは・・・　user/1/blog/1/post/10/comment/1・・・・？？

　ただ、パスを考えるとネストする度にどんどん深くなっていき直感的とは言い難いです。
実際に私が読んだ記事などでもネストは１、２つまでと書かれていることが多いです。

　ユーザの配下に直接postsも配置させる？
けど、commentsも入れると結局３階層？？？？ムムム？？
form_forとか一体どこに飛んでいくだ？？？と混乱してしまいました。

◾️教えて欲しいこと
モデルのアソシエーション自体は必要だと思うため、問題ないと思っています。
ただ、これらを表す時のRoutes.rbファイルのネストのさせかたの基本が分からず、
通常どうやって浅くしているものか、参考となるページなどがあれば、ご教示いただきたいなと考えております。

初学者で基本中の基本すぎて大変恐縮ではありますが、何かアドバイスをいただければ嬉しいです。
拙い文章ばかりで申し訳ありませんが、よろしくお願いいたします。

Answer 1

すみません、解決済みになっていますが回答させていただきます。

resourcesをネストさせることはまぁまぁの頻度であります。
特に親子関係をもつテーブルがあり、それぞれ親に紐づくデータのみを扱いたいときなどです。

ただURLが長くなってしまうというのはよくある悩みで、そういった場合
:user_id/:blog_id/:post_id/coments/:idのような形にカスタマイズすることはあります。
よく見るのはIDではなくユーザー名とかですかね。Qiitaなども
ユーザー名/items/識別IDのような形ですし。

ただ、やはりその親を示す情報を送ってやらないと親を判別できないので
/blogs,/commentsのようなパスでは
特定のユーザーのブログや特定の記事のコメントのみを扱うようなことができません。

そういったスコープを絞ったレコードの操作が不要なのであれば話は別ですが...。

URLの見た目に関してはshallow nestという方法があるそうです。
見た目についてはこの方法を用いればスッキリしそうです。

Comments

[maisumakun]

shallow nestという方法があって、既存のIDが無いnewやcreateだけネスト、IDのあるshowなどは独自に管理する、というようなことも可能です。

https://railsguides.jp/routing.html#%E3%80%8C%E6%B5%85%E3%81%84%E3%80%8D%E3%83%8D%E3%82%B9%E3%83%88

[rhiroe]

おー知らなかったです。ありがとうございます。
でもやっぱりネストはしないといけないのは変わらずですね。
URLの見た目の問題は解決できそうです。

[zackieeee]

ありがとうございます！

なるほど、ネストさせることでController以降の処理を軽減させる効果もあると理解しました！
shallowは、ガイドで読んでいたのですが今一ピンと来ていませんでした。
例えば、質問構成のネストで、commentをnewとeditした場合、以下のようにID不要なものについてURLをスッキリさせてくれる効果がある！と理解しました！
　・new(id不要)　→ /user/blog/post/comment/new
　・edit(id必要)　→ /user/1/blog/1/post/1/comment/1/edit

閉じておきながら、更に質問で申し訳なのですが…
　①ネストさせたモデルのINDEX
　　→ネストさせてしまった場合、親を指定せずに全てを表示させることは出来なくなるのでしょうか？
　②識別IDについて
　　→ちょっと主題とずれてしまうのですが、
　　　例えばhas_oneの関係にあるものについて、
　　　cookpadなどを見ていると、識別IDをユーザID（？）で統一しているように見受けられます。
　　　IDを特定のIDで統一すると言うことも可能なのでしょうか？？？

すみません、トンチンカンな事を言っている可能性もあり、大変恐縮ですが…よろしくお願いしますmm

[rhiroe]

① そんなことはありません、できます

② 可能です。
というより全て親レコードのid(？)を使っているだけのことでしょう。
kitchen/親レコードid => 親レコードに紐づくkitchenページ
recipe/list/親レコードid => 親レコードに紐づくrecipe一覧
みたいな感じですかね。
「親に紐づく子レコード群のみを表示するときは親レコードの情報が必要」とはこういうことです。

[zackieeee]

①ありがとうございます！承知しました！

②心強いです！
　初学者のため、今一ピンときていないのですが、
　例えばuser/1(user_id)/blog/3(blog_id)などのルーティングは、newないしcreateされた時のタイミングで一意に決まるプライマリキーが自動割り当てされると言う感覚です。
　そのためuser_id = blog_idになっていないと、namespaceやshallowしたとしても、
　blog/3(blog_id) (≠ user_id)となりそうですが、id自体を親ネストのIDにも 出来るんですね!(?▼?)!
話が逸れすぎてるので、こちらはもう少し自力でも学習してみようと思います＞＜

　すみません、色々とご教示いただきありがとうございます！

Answer 2

Modelの階層に合わせて　controller、URL、routes を階層化する必要はありません。管理者とユーザで違うことをしたいとか、複数のsub-systemを分けて管理したいというような目的で
namespace :admin
resources :blogs
というような階層化はよくやりますが。

Userにアクセスするには　/users
そのblogにアクセスするには /blogs
で良いと思うのですがどうでしょう。

Comments

[zackieeee]

ありがとうございました！
頂いた内容からするとresourcesをネストさせるのは、通常あまりやらないこと、と理解しました。

合わせて、いくつか新たな疑問点ご教示いただけると幸いです。

・resourcesをネストさせるメリットってなんなんでしょう…
　→論理的な階層構造が気持ち分かりやすくなるぐらいなんでしょうか？
　　ただ、ネストしすぎると結局余計に分かりにくくなるため、下手に実装するのは辞めた方がいい…
・回答にあるSub-Systemを別けるとはどう言うイメージなのでしょうか？？
　→Controllerを分割したけど、ネストさせずにカテゴリ的には一緒だよ！って表記したいとかでしょうか…

初心者で本当に申し訳ありません。
よろしくお願いいたします。

[winterboum]

・resourcesをネストさせるメリットってなんなんでしょう…
　namespaceでなく、ですか？　それですとわかりません。

・回答にあるSub-Systemを分ける
あまり良い例ではないですが、私のサイトでは
MSDN Top 線形計画法 複式簿記 太陽光発電 勤務割付 ユーザメンテ オプション 気象 予報 ヘルプメンテ HowTo 倉庫管理
という無関係のものが寄せ集めてあるので、一緒くたでは収集つかなくなるので、分けています。
よく有るかも、なのは　マスター、受注、発送、請求・入金、経理　みたいなので分ける

[zackieeee]

回答が遅くなってしまい、すみません！！

resourcesをネストさせるより、namespaceを使用する方が一般的と理解しました。
これは階層構造自体に機能的な意味を持たせるとメンテナンス性が低下するリスクが生じるからと言う解釈です。

また、サブシステムについても、どう分けるかはシステム設計やシステムの性格によるって感じですね。
例にあげて頂いたサイトでは、各業務（？）ごとに同じ処理の流れを持っているので、その流れごとにnamespaceを作って流って感じでしょうか？
それともマスターに所属するものは、ヘルプ、メンテナンス、HowTo。発送は倉庫管理…とかって感じかな。。。

今回私が作ろうとしているアプリもnamespaceをつけて、論理的にカテゴライズしてみようと思います。
ありがとうございます！

[winterboum]

もうひとつnamespaceを使う典型的なのがありました。
管理者としての業務と一般ユーザとしての業務を分けるためにnamespaceで切り分けることを良くやります

[zackieeee]

ありがとうございます！
管理者と一般ユーザを分けるための例は、ご教示いただいた後探してみた結果、たくさん出てきました！
この切り分け是非取り入れたいと思います！！！！